認証方式

PostgreSQL 8.0.0 文書
前のページ | 巻戻し | 第 19章クライアント認証 | 早送り | 次のページ

# 19.2. 認証方式

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

## 19.2.1. Trust認証

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

`trust`認証はユーザが一人のみのワークステーション上でローカル接続を行う場合は適切であると同時に非常に便利です。 複数ユーザが存在するマシン上では一般的に適切ではありません。 とはいっても、ファイルシステムの許可属性を使ってサーバのUnixドメインソケットファイルへのアクセスを制限すれば`trust`認証を複数ユーザのマシン上で使用することも可能です。 その方法は、項16.4.2に記載されているように`unix_socket_permissions`（および`unix_socket_group`パラメータの可能性もあります）パラメータを設定します。 もしくは、`unix_socket_directory`設定パラメータでソケットファイルをそれに相応しく制限がかかっているディレクトリにします。

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

## 19.2.2. パスワード認証

パスワードをベースにした認証方式には `md5`、`crypt`, および `password` があります。 これらの方式はパスワードが接続間でどのように送信されるかを別にすれば似たような振舞いをします。 しかし、`md5`のみが`pg_shadow`内に格納された暗号化パスワードをサポートします。 この他の2つでは、ここには平文のパスワードが必要です。

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

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

## 19.2.3. Kerberos 認証

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 の場合は `/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 を通して安全なデータベースアクセスができます。

## 19.2.4. Ident ベースの認証

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

### 19.2.4.1. TCP/IP 経由の Ident 認証

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

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

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

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

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

`SO_PEERCRED` 要求のないシステム上では TCP/IP 接続に対してのみ ident 認証が使えます。 使ってみるには localhost アドレス 127.0.0.1 を指定してこのアドレスに接続してください。 この方法はの信頼性は、ローカルなidentサーバが信頼できる範囲までです。

### 19.2.4.3. Ident マップ

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

`sameuser`以外のidentマップは、デフォルトでクラスタのデータディレクトリにある`pg_ident.conf`という名前のidentマップファイルで定義されます。 (しかし、他の場所にマップファイルを設置することもできます。 ident_file設定パラメータを参照してください。) 通常、identマップファイルは以下の書式を持ちます。

    map-name ident-username database-username

コメントと空白は`pg_hba.conf`と同様にに扱われます。 `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` でも接続を許可されます。

例 19-2. `pg_ident.conf` ファイルの例

    # マップ名     IDENT ユーザ名    Postgresqlユーザ名

    omicron       bryanh            bryanh
    omicron       ann               ann
    # bobはこのマシン内ではrobertというユーザ名を持つ
    omicron       robert            bob
    # bryanh はguest1としても接続可能
    omicron       bryanh            guest1

## 19.2.5. PAM 認証

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

前のページ | ホーム | 次のページ
クライアント認証 | 上に戻る | 認証における問題点