他のバージョンの文書 16 | 15 | 14 | 13 | 12 | 11 | 10 | 9.6 | 9.5 | 9.4 | 9.3 | 9.2 | 9.1 | 9.0 | 8.4 | 8.3 | 8.2 | 8.1 | 8.0 | 7.4 | 7.3 | 7.2

4.2. 認証方式

以下では、認証方式について詳細に説明します。

4.2.1. Trust 認証

trust 認証が指定されると PostgreSQL は、postmaster に接続できる誰もが(データベーススーパーユーザーも含め)postmaster が特定するいかなるデータベースユーザーであれアクセス権限が付与されていると想定します。この方式は postmaster ポートに接続するに際して適切なシステムレベルの保護がかけられている場合にのみ使用すべきです。

trust 認証はシングルユーザーのワークステーション上では適切であると同時に便利です。マルチユーザーのマシン上では一般的に適切ではありません。とはいっても、ファイルシステムの許可属性を使って postmaster のソケットファイルへのアクセスを制限すれば trust 認証をマルチユーザーのマシン上で使用することも可能です。その方法は、Section 3.4.3 に記載されているように postgresql.confunix_socket_permissions (および unix_socket_group の可能性も)パラメータを設定します。もしくは、unix_socket_directory の設定でソケットファイルをそれに相応しく制限がかかっているディレクトリにします。

ファイルシステムの許可属性設定は Unix ソケット接続にのみ有効です。ローカル TCP 接続では制限がかかりません。ですから、ローカルにおけるセキュリティとして許可属性を使用したいのであれば、pg_hba.confhost ... 127.0.0.1 ... の行を削除するか、もしくは非 trust 認証方式に変更して下さい。

trust 認証は trust を指定する pg_hba.conf の行によって postmaster に接続を許可されるすべてのマシン上のすべてのユーザーを信用 (trust) できる場合にのみ相応しいものです。ローカルホスト(127.0.0.1)以外からの TCP 接続に trust 認証をもちいる理由はほとんど見当たりません。

4.2.2. パスワード認証

パスワードをベースにした認証方式には md5crypt,および password があります。これらの方式はパスワードが接続間でどのように送信されるかを別にすれば似たような振舞をします。もしパスワード「盗聴」攻撃に最大の関心があれば md5 を使うのが良いでしょう。二番目の選択として、すでに存在しないクライアントのサポートも必要であれば crypt を使います。単純な password は (SSL、SSH、 あるいは接続前後を含めた他の通信セキュリティ用のラッパーを使わない限り)特にオープンなインターネット環境での接続に使用することを避けなければなりません。

PostgreSQL データベースパスワードはオペレーティングシステムのユーザーパスワードとも別のものです。通常、それぞれのデータベースユーザーのパスワードは pg_shadow システムカタログテーブルの中に格納されます。 CREATE USER foo WITH PASSWORD 'secret'; のようにパスワードは問い合わせ言語のコマンド CREATE USERALTER USER で使って管理できます。デフォルトではもしパスワードが設定されない場合、格納されるパスワードは NULL となって、そのユーザーのパスワード認証は常に失敗に終ります。

特定のデータベースに接続することを許可するユーザーの集合を制限するために、 pg_hba.conf がある場所と同じディレクトリに、別のファイルでユーザーの集合を (1 行に 1 ユーザーづつ)リストアップし、 pg_hba.conf の中の password もしくは crypt キーワードのそれぞれの後ろに(基本)ファイル名を列挙します。もしこの機能を使わなければ、データベースシステムに認識されるすべてのユーザーはすべてのデータベースに接続することができます(もちろん、そのユーザーが正しいパスワードを入力するとしてですが)。

これらのファイルは、異なるパスワードの集合を特定のデータベースもしくはその集合に適用するために使われます。その場合、ファイルは標準 Unix パスワードファイル /etc/passwd に似たフォーマットで、次のようになります。

username:password

パスワードの後にコロンで区切られたフィールドがあってもすべて無視されます。パスワードはシステムの crypt() 関数を使って暗号化される前提になっています。PostgreSQL と一緒にインストールされるユーティリティプログラム pg_passwd をこれらのパスワードファイルを管理するために使えます。

パスワードがある行とない行は、二次のパスワードファイルの中で混在させることができます。パスワードがない行は、CREATE USERALTER USER によって管理される pg_shadow の中のメインパスワードを使用することを示します。パスワードがある行はそのパスワードの使用を強要します。"+" というパスワード入力項目もやはり pg_shadow のパスワードを使うことを意味します。

crypt 方式を使う場合、代替パスワードは使えません。ファイルはいつものように評価されますが、パスワードフィールドは単に無視されて pg_shadow のパスワードが常に使われます。

このように代替パスワードを使うことは、パスワードを変更するために ALTER USER を使うことができなくなることを意味します。機能するように見えるかもしれませんが、変えられたパスワードはシステムが使わなくてはならないパスワードではありません。

4.2.3. Kerberos 認証

Kerberos は業界標準の安全な認証システムで、公開ネットワークにまたがった分散処理に適しています。 Kerberos システムの説明はこの文書の範囲外で、概ねとても(強力ですが)複雑なものといえます。 Kerberos FAQ あるいは MIT Project Athena が探索を開始するにはお勧めです。 Kerberos のソースコード配布物はいくつか存在します。

Kerberos を使うには、構築時にサポートするように指定しなくてはなりません。ひとつのビルドではいずれかのバージョンだけのサポートとなりますが、./configure --with-krb4 もしくは ./configure --with-krb5 とすることで Kerberos 4 と 5 の両方ともサポートされます。

PostgreSQL は通常の Kerberos サーバのように動作します。サービスのプリンシパル名は servicename/hostname@realm で、(コンフィギュレーション時に ./configure --with-krb-srvnam=whatever で別のサービス名が選択されない限り) servicenamepostgres です。hostname はサーバマシンの完全にその資格を取得しているドメイン名です。サービスプリンシパルのrealm はサーバマシンが提起した realm です。(訳注:プリンシパルとはおざっぱに二つのものをさします。ひとつはサービスを受けるクライアントで、もうひとつはサービスを提供するサーバアプリケーションです。どちらも、認証に関しては Kerberos の KDC からみるとクライアントになります。)

クライアントのプリンシパルは第一の構成要素として PostgreSQL のユーザー名を所有しなければなりません。例えば、 pgusername/otherstuff@realm です。現時点ではクライアントの realm は PostgreSQL でチェックされません。ですから、相互の realm 認証が使用可能になっていれば、自身と通信可能ないかなる realm のどのようなプリンシパルであっても許可されます。

サーバの鍵は PostgreSQL サーバアカウントによってが読み込み可能(そしてできれば読み込み専用)であることを確認してください(Section 3.1 を参照)。鍵ファイルの保存場所は krb_server_keyfile 実行時コンフィギュレーションパラメータで指定されます。(Section 3.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.COMfred/users.example.com@EXAMPLE.COM 両方のプリンシパルがデータベースサーバの認証に使用されます。

Apache Web サーバ上で mod_auth_krbmod_perl 使うのであれば mod_perlAuthType KerberosV5SaveCredentials が使用可能です。この方法により余分のパスワードを必要とせず、 Web を通して安全なデータベースアクセスができます。

4.2.4. Ident ベースの認証

"身元特定(Identification)プロトコル"については RFC 1413 で説明されています。事実上すべてのUnix 系のオペレーティングシステムの配布には、デフォルトで TCP ポート 113 を監視する ident サーバーが付属しています。ident サーバーの基本的な機能は"どのユーザーがポート X からの接続を開始し、自分のポート Y に接続するのか?"というような質問に答えることです。 PostgreSQL は物理的な接続が確立されたときに XY の両方を認識するので、接続するクライアントのホスト上の ident サーバーに応答指令信号を送ることができ、理論的には、この方法で与えられたどの接続にもオペレーティングシステムユーザーを決定できます。

この手続きの欠点は、クライアントの正直さに頼るところが大きいということです。もしクライアントマシンが信用されない、もしくは危険に晒されている場合、攻撃者はポート 113 上でほぼどんなプログラムでも実行することができ、どのユーザー名でも好きに選んで返すことができます。したがってこの認証方式は、各々のクライアントマシンが厳格な管理下にあり、データベースとシステム管理者が密接に連絡をとりあって動作している、外界から閉ざされたネットワークにのみ適しているといえます。言い替えると、ident サーバが稼働しているマシンを信用しなければなりません。次の警告に注意してください。
 

身元特定プロトコルは、認証、あるいはアクセス管理プロトコルには意図されていません。

 
--RFC 1413 

Unix ドメインソケットに対して SO_PEERCRED 要求をサポートしているシステム上ではローカル接続に対しても ident 認証が適用可能です。この場合、ident 認証使用による危険はありません。実際このようなシステム上のローカル接続には推奨される選択です。

ident ベースの認証を使う場合、接続を開始したオペレーティングシステムユーザーを決定すると、PostgreSQL はあるデータベースシステムユーザーとして接続要求をしてきているユーザーが接続を許可されているかを調べます。これは pg_hba.conf ファイルの中の ident キーワードの後にくる ident マップ引数によって制御されます。既に定義済の ident マップ sameuser があって、どのオペレーティングシステムユーザーであっても、同じ名前を持つデータベースユーザー(もし存在すれば)として接続できるように許可します。その他のマップは手作業で作らなければいけません。

sameuser 以外の ident マップはデータディレクトリの 普通の形式で行が書かれている pg_ident.conf ファイルで定義されます。

map-name ident-username database-username

コメントと空白はいつものとおりに扱われます。map-namepg_hba.conf の中でこのマッピングを参照するために使われる任意の名前です。他の 2 つのフィールドはどのオペレーティングシステムユーザーがどのデータベースユーザーで接続することが許可されるかを指定します。同じ map-name をひとつのマップの中で、別のユーザーマッピングを指定するためにくり返し使うことができます。何人のデータベースユーザーが与えられたオペレーティングシステムユーザーに対応するのか、またはその逆に関しての制限はありません。

pg_hba.conf ファイルは起動時と、 postmasterSIGHUP 信号を受け取ったときに読み込まれます。稼働中のシステムでファイルを編集した場合は、(pg_ctl reload あるいは kill -HUP を使用して)postmaster にファイルをもう一度読み込むように信号を出さなければなりません。

Example 4-1 にある pg_hba.conf と一緒になって使用可能な pg_ident.conf ファイルは Example 4-2 で示されています。この設定の例では、192.168 ネットワーク上のマシンに bryanhann、または robert という Unix ユーザー名を所有しない人はアクセスを許可されません。Unix ユーザー robertPostgreSQL ユーザー bob として接続する時だけ許可されます。 robert とかそれ以外の名前としてではありません。annann としてでしか接続許可されません。ユーザー bryanh は彼自身である bryanh でも guest1 でも接続を許可されます。

Example 4-2. pg_ident.conf ファイルの例

#MAP           IDENT-NAME   POSTGRESQL-NAME

omicron        bryanh       bryanh
omicron        ann          ann
# bob has username robert on these machines
omicron        robert       bob
# bryanh can also connect as guest1
omicron        bryanh       guest1