以下では、認証方式について詳細に説明します。
trust 認証が指定されると PostgreSQL は、サーバに接続できる全ての人に対して (データベーススーパーユーザも含め) その人が指定する任意のデータベースユーザとしてのアクセス権限が付与されていると想定します。 この方式はサーバに接続するに際して適切なシステムレベルの保護がかけられている場合にのみ使用すべきです。
trust 認証はユーザが一人のみのワークステーション上では適切であると同時に便利です。 複数ユーザが存在するのマシン上では一般的に適切ではありません。 とはいっても、ファイルシステムの許可属性を使ってサーバのソケットファイルへのアクセスを制限すれば trust 認証を複数ユーザのマシン上で使用することも可能です。 その方法は、項16.4.1 に記載されているようにunix_socket_permissions（および unix_socket_group の可能性も）パラメータを設定します。 もしくは、unix_socket_directory 設定パラメータでソケットファイルをそれに相応しく制限がかかっているディレクトリにします。
ファイルシステムの許可属性設定は Unix ソケット接続にのみ有効です。 ローカル TCP 接続では制限がかかりません。 ですから、ローカルにおけるセキュリティとして許可属性を使用したいのであれば、pg_hba.conf の host ... 127.0.0.1 ... の行を削除するか、もしくは非 trust 認証方式に変更して下さい。
trust 認証は trust を指定する pg_hba.conf の行によってサーバに接続を許可されるすべてのマシン上のすべてのユーザを信用 (trust) できる場合にのみ相応しいものです。 ローカルホスト（127.0.0.1）以外からの TCP 接続に trust 認証をもちいる理由はほとんど見当たりません。
パスワードをベースにした認証方式には md5、crypt, および password があります。 これらの方式はパスワードが接続間でどのように送信されるかを別にすれば似たような振舞をします。 もしパスワード「盗聴」攻撃に最大の関心があれば md5 を使うのが良いでしょう。 二番目の選択として、バージョン 7.2 より前のクライアントのサポートも必要であれば crypt を使います。 単純な password は (SSL、SSH、あるいは接続前後を含めた他の通信セキュリティ用のラッパを使わない限り)特にオープンなインターネット環境での接続に使用することを避けなければなりません。
PostgreSQL データベースパスワードはオペレーティングシステムのユーザパスワードとも別のものです。 各データベースユーザのパスワードは pg_shadow システムカタログテーブルの中に格納されます。 CREATE USER foo WITH PASSWORD 'secret'; のようにパスワードは問い合わせ言語のコマンド CREATE USER と ALTER USER で使って管理できます。 デフォルトでは、パスワードが設定されない場合、格納されるパスワードは NULL となり、そのユーザのパスワード認証は常に失敗します。
特定のデータベースに接続することを許可するユーザの集合を制限するには、前節の説明のように、pg_hba.confのuser列にユーザのリストを指定してください。
Kerberos は業界標準の安全な認証システムで、公開ネットワークにまたがった分散処理に適しています。 Kerberos システムの説明はこの文書の範囲外で、概ねとても(強力ですが)複雑なものといえます。 KerberosFAQ あるいは MIT Athenaプロジェクト が探索を開始するにはお勧めです。 Kerberos のソースコード配布物はいくつか存在します。
PostgreSQL はKerberos4とKerberos5の両方をサポートしていますが、お勧めできるのはKerberos 5のみです。 Kerberos 4 は安全ではないと考えられており、通常の使用に推奨することはできません。
Kerberos を使うには、構築時にサポートするように指定しなくてはなりません。 より詳細については 第14章 を参照して下さい。 Kerberos 4 と 5 は両方ともサポートされますが、ひとつのビルドではいずれかのバージョンだけのサポートとなります。
PostgreSQL は通常の Kerberos サービスのように動作します。 サービスのプリンシパル名は servicename/hostname@realm で、(構築時に ./configure --with-krb-srvnam=whatever で別のサービス名が選択されない限り) servicename は postgres です。 hostname はサーバマシンの完全修飾されたホスト名です。 サービスプリンシパルの realm はサーバマシンが提起した realm です。(訳注：プリンシパルとはおおざっぱに二つのものをさします。ひとつはサービスを受けるクライアントで、もうひとつはサービスを提供するサーバアプリケーションです。どちらも、認証に関しては Kerberos の KDC からみるとクライアントになります。)
クライアントのプリンシパルは第一の構成要素として PostgreSQL のユーザ名を所有しなければなりません。 例えば、pgusername/otherstuff@realm です。 現時点ではクライアントの realm は PostgreSQL でチェックされません。 ですから、相互の realm 認証が使用可能になっていれば、自身と通信可能ないかなる realm のどのようなプリンシパルであっても許可されます。
サーバ鍵ファイルが PostgreSQL サーバアカウントによって読み込み可能（そしてできれば読み込み専用）であることを確認してください（項16.1 を参照してください）。 鍵ファイルの保存場所は krb_server_keyfile 実行時設定パラメータで指定されます。 （項16.4 を参照してください。） デフォルトは、Kerberos 4 を使っている場合は /etc/srvtabで、Kerberos 5 の場合は FILE:/usr/local/pgsql/etc/krb5.keytab（もしくはビルド時に sysconfdir で指定されたディレクトリ）です。
keytabファイルの生成には、たとえば（version 5 では）以下のようにします。
kadmin% ank -randkey postgres/server.my.domain.org kadmin% ktadd -k krb5.keytab postgres/server.my.domain.org
詳細については Kerberos の文書を参照ください。
データベースに接続しようとしている時要求されるデータベースユーザ名に一致するプリンシパルのチケットを所有しているか確認してください。 例えば、データベースユーザ名 fred に対し、fred@EXAMPLE.COM と fred/users.example.com@EXAMPLE.COM 両方のプリンシパルがデータベースサーバの認証に使用されます。
Apache Web サーバ上で http://modauthkerb.sf.netで提供されるmod_auth_krb と mod_perl 使うのであれば mod_perl スクリプトで AuthType KerberosV5SaveCredentials が使用可能です。 この方法により余分のパスワードを必要とせず、 Web を通して安全なデータベースアクセスができます。
ident 認証方式は、クライアントのオペレーティングシステムのユーザ名を検査して、許可された対応するユーザ名のペアが列挙されているマップファイルを使用して、許可されているデータベースのユーザ名を判断します。 クライアントのユーザ名の決定はセキュリティの重大なポイントであり、接続の形式によって異なる働きをします。
"身元特定（Identification）プロトコル"については RFC 1413 で説明されています。 事実上すべての Unix 系のオペレーティングシステムの配布には、デフォルトで TCP ポート 113 を監視する ident サーバが付属しています。 ident サーバの基本的な機能は"どのユーザがポート X からの接続を開始し、自分のポート Y への接続を初期化したのか？"というような質問に答えることです。 PostgreSQL は物理的な接続が確立された時に X と Y の両方を認識するので、接続するクライアントのホスト上の ident サーバに応答指令信号を送ることができ、理論的には、この方法で与えられたどの接続にもオペレーティングシステムユーザを決定できます。
この手続きの欠点は、クライアントの正直さに頼るところが大きいということです。 もしクライアントマシンが信用されない、もしくは危険に晒されている場合、攻撃者はポート 113 上でほぼどんなプログラムでも実行することができ、どのユーザ名でも好きに選んで返すことができます。 したがってこの認証方式は、各々のクライアントマシンが厳格な管理下にあり、データベースとシステム管理者が密接に連絡をとりあって動作している、外界から閉ざされたネットワークにのみ適しているといえます。 言い替えると、ident サーバが稼働しているマシンを信用しなければなりません。 次の警告に注意してください。
身元特定プロトコルは、認証、あるいはアクセス管理プロトコルには意図されていません。 | ||
| --RFC 1413 | ||
Unix ドメインソケットについて SO_PEERCRED 要求をサポートしているシステム (現時点では Linux、FreeBSD、NetBSD、OpenBSD、およびBSD/OS) 上では、ローカル接続に対しても ident 認証を適用できます。 この場合、ident 認証使用による危険はありません。 実際、このようなシステム上のローカル接続では推奨される方法です。
SO_PEERCRED 要求のないシステム上では TCP/IP 接続に対してのみ ident 認証が使えます。 使ってみるには localhost アドレス 127.0.0.1 を指定してこのアドレスに接続してください。
ident ベースの認証を使う場合、接続を開始したオペレーティングシステムユーザ名を決定すると、PostgreSQL はあるデータベースシステムユーザとして接続要求をしてきているユーザが接続を許可されているかを調べます。 これは pg_hba.conf ファイルの中の ident キーワードの後にくる ident マップ引数によって制御されます。 既に定義済の ident マップ sameuser があります。これは、どのオペレーティングシステムユーザであっても、同じ名前を持つデータベースユーザ(もし存在すれば)として接続できるように許可します。 その他のマップは手作業で作らなければいけません。
sameuser以外のidentマップは、データディレクトリにあるpg_ident.confファイルで定義されます。 通常は以下の書式を持ちます。
map-name ident-username database-username
コメントと空白はいつものとおりに扱われます。 map-name は pg_hba.conf の中でこのマッピングを参照するために使われる任意の名前です。 他の 2 つのフィールドはどのオペレーティングシステムユーザがどのデータベースユーザで接続することが許可されるかを指定します。 同じ map-name をひとつのマップの中で、別のユーザマッピングを指定するためにくり返し使うことができます。 何人のデータベースユーザが与えられたオペレーティングシステムユーザに対応するのか、またはその逆に関しての制限はありません。
pg_ident.conf ファイルは起動時と、主となるサーバプロセス(postmaster)が SIGHUP 信号を受け取った時に読み込まれます。 稼働中のシステムでファイルを編集した場合は、（pg_ctl reload あるいは kill -HUP を使用して）postmaster にファイルを再読み込むように信号を送らなければなりません。
例19-1 にある pg_hba.conf と一緒になって使用可能な pg_ident.conf ファイルは 例19-2 で示されています。 この設定例では、 bryanh、ann、または robert という Unix ユーザ名以外で、192.168 ネットワーク上のマシンにログインしたユーザはアクセスを許可されません。 Unix ユーザ robert は PostgreSQL ユーザ bob として接続する時だけ許可されます。 robert とかそれ以外の名前としてではありません。 ann は ann としてでしか接続許可されません。 ユーザ bryanh は彼自身である bryanh でも guest1 でも接続を許可されます。
この認証方式は認証機構として PAM（Pluggable Authentication Modules）を使用することを除いて password のように働きます。 デフォルトの PAM サービス名は postgresql です。 pg_hba.confファイルの pam キーワードに続けて、オプションで独自のサービス名を指定することができます。 PAM についてより詳しくは Linux-PAM ページ と Solaris PAM ページ を読んでください。