他のバージョンの文書 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

6.2. 認証方式

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

6.2.1. Trust 認証

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

trust 認証はシングルユーザーのワークステーション上では適切であると同時に便利です。 マルチユーザーのマシン上では一般的に適切ではありません。 とはいっても、ファイルシステムの許可属性を使って postmaster のソケットファイルへのアクセスを制限すれば trust 認証をマルチユーザーのマシン上で使用することも可能です。 その方法は、Section 3.4.4 に記載されているように 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 の行によってサーバに接続を許可されるすべてのマシン上のすべてのユーザーを信用 (trust) できる場合にのみ相応しいものです。 ローカルホスト(127.0.0.1)以外からの TCP 接続に trust 認証をもちいる理由はほとんど見当たりません。

6.2.2. パスワード認証

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

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

特定のデータベースに接続することを許可するユーザーの集合を制限するには、ユーザーをカンマで区切ってリストするか、または別のファイルにリストします。 このファイルではユーザー名をカンマで区切るか、または 1 行につき 1 つのユーザー名をリストアップし、ファイルは pg_hba.conf と同じディレクトリに存在する必要があります。 このファイルの (ベース) ファイル名の前に @ を付けて、ユーザ列に記載します。 データベース列でも同様に値のリストやファイル名を使用することができます。 グループ名も、そのグループ名の前に + を付けることで指定できます。

6.2.3. Kerberos 認証

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

Kerberos を使うには、構築時にサポートするように指定しなくてはなりません。 より詳細については Chapter 1 を参照して下さい。 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 を通して安全なデータベースアクセスができます。

6.2.4. Ident ベースの認証

ident 認証方式は、クライアントのオペレーティングシステムのユーザー名を検査して、許可されているデータベースのユーザー名を判断します。ユーザー名の判断には、許可された対応するユーザー名のペアが列挙されているマップファイルを使用します。 クライアントのユーザー名の決定はセキュリティの重大なポイントであり、接続の形式によって異なる働きをします。

6.2.4.1. TCP/IP 経由の Ident 認証

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

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

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

 
--RFC 1413 

6.2.4.2. ローカルソケット経由の Ident 認証

Unix ドメインソケットについて SO_PEERCRED 要求をサポートしているシステム (現時点では LinuxFreeBSDNetBSD、およびBSD/OS) 上では、ローカル接続に対しても ident 認証を適用できます。 この場合、ident 認証使用による危険はありません。実際、このようなシステム上のローカル接続では推奨される方法です。

SO_PEERCRED 要求のないシステム上では TCP/IP 接続に対してのみ ident 認証が使えます。 使ってみるには localhost アドレス 127.0.0.1 を指定してこのアドレスに接続してください。

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

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

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

# MAPNAME     IDENT-USERNAME    PG-USERNAME

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

6.2.5. PAM 認証

認証の形式は認証機構として PAM(Pluggable Authentication Modules)を使用することを除いて password のように働きます。 デフォルトの PAM サービス名は postgresql です。 ファイルの pam キーワードに続けて、オプションで独自のサービス名を指定することができます。 PAM についてより詳しくは Linux-PAM PageSolaris PAM Page を読んでください。