無料スクリプト配布のPHP.TO   PHPの実用的なtips PHPマニュアル MySQLマニュアル Apacheマニュアル PostgreSQLマニュアル マニュアル検索    

19.3. 認証方式

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

19.3.1. Trust認証

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

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

Unixソケット接続を行うただ1つの方法は、ファイルシステムの許可を設定することです。 ローカルのTCP/IP接続は、ファイルシステムにより制限はされていません。 よってローカルでファイルシステムの許可を使用したい場合は pg_hba.conf から host ... 127.0.0.1 ... の行を削除するか、 trust 認証とは異なる方法に変更する必要があります。

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

19.3.2. パスワード認証

パスワードをベースにした認証方式には md5 および password があります。 これらの方式はパスワードが接続間でどのように送信されるか(すなわち、それぞれMD5-hashed、平文)を別にすれば似たような動作をします。

もしパスワード "盗聴" 攻撃に最大の関心があれば md5 を使うのがよいでしょう。 可能ならば、平文の password の使用は常に避けなければなりません。 しかし md5 db_user_namespace 機能といっしょに使用することはできません。 接続がSSL暗号化により保護されているのであれば、 password を安全に使用することができます。 (ただしSSLの使用に依存するという点では、SSL証明書認証を使用した方が良いかもしれません。)

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

19.3.3. GSSAPI認証

GSSAPI は、RFC 2743で定義されている安全な認証のための業界標準のプロトコルです。 PostgreSQL は、RFC 1964により Kerberos 認証と共に GSSAPI をサポートします。 GSSAPI は、 GSSAPI をサポートしているシステムに対して自動認証(シングルサインオン)を提供します。 認証自体は安全ですが、データベース接続を通じて送信されるデータは、 SSL が使用されていない場合は平文となります。

GSSAPI Kerberos を使用しているとき、 GSSAPI は、 servicename / hostname @ realm の書式において標準の原則を使用します。 原則についての情報や、どのようにして要求された鍵を設定するのかについては 項19.3.5 を参照してください。

GSSAPIサポートは、 PostgreSQL が構築されたときに使用可能となります。詳細は、 第15章 を参照してください。

次の設定オプションは GSSAPI のためにサポートされています。

include_realm

1 に設定されている場合は、認証されたユーザプリンシパルからのrealm名が、 ユーザ名マッピング( 項19.2 )で渡されるシステムユーザ名の中に含まれています。 これは複数realmからのユーザを扱う場合に便利です。

map

システムとデータベースの間のマッピングを許可します。詳細は 項19.2 を参照してください。 Kerberosプリンシパルに対しては user name/hostbased@EXAMPLE.COM 、もし include_realm が 無効になっている場合はマッピングに対して使用されるユーザ名は user name/hostbased include_realm が有効になっている場合は user name/hostbased@EXAMPLE.COM です。

krb_realm

realmをユーザプリンシパル名に一致するように設定します。もしこのパラメータが設定されている場合は realmのユーザのみが受け付けられます。もしこれが設定されていない場合は、 どのようなrealmのユーザも接続可能で、ユーザ名マッピングが設定されていれば、どれでも影響を受けます。

19.3.4. SSPI認証

SSPI は、シングルサインオンで安全な認証を行うための Windows の技術です。 PostgreSQL は、 negotiate モードにおいてSSPIを使用します。 これは、可能な場合は Kerberos を使用し、他の場合については自動的に NTLM を使用することを意味しています。 SSPI 認証は、サーバ、クライアントが共に Windows 上もしくは GSSAPI が利用可能な場合はWindowsではないプラットフォームで稼動しているときにのみ動作します。

Kerberos 認証を使用しているとき、 SSPI は、 GSSAPI と同じように動作します。 詳細は 項19.3.3 を参照してください。

次の設定オプションは SSPI のためにサポートされています。

include_realm

1 に設定されている場合は、認証されたユーザプリンシパルからのrealm名が、 ユーザ名マッピング( 項19.2 )で渡されるシステムユーザ名の中に含まれています。 これは複数realmからのユーザを扱う場合に便利です。

map

システムとデータベースユーザ名の間のマッピングを許可します。 詳細は 項19.2 を参照してください。

krb_realm

realmをユーザプリンシパル名に一致するように設定します。もしこのパラメータが設定されている場合は realmのユーザのみが受け付けられます。もしこれが設定されていない場合は、 どのようなrealmのユーザも接続可能で、ユーザ名マッピングが設定されていれば、どれでも影響を受けます。

19.3.5. Kerberos認証

注意: ネイティブのKerberos認証は、推奨されず互換性のためのみに使用されるべきです。新規に更新されたインストールは業界標準の GSSAPI 認証を使用することを推奨しています。(詳細は 項19.3.3 を参照してください)

Kerberos は業界標準の安全な認証システムで、公開ネットワークにまたがった分散処理に適しています。 Kerberos システムの説明はこの文書の範囲外で、概ねとても(強力ですが)複雑なものと言えます。 Kerberos FAQ あるいは MIT Kerberosページ が探索を開始するにはお勧めです。 Kerberos のソースコード配布物はいくつか存在します。 Kerberos は安全な認証を提供しますが、ネットワーク越しに渡される問い合わせやデータの暗号化を行いません。 このためには SSL を使用してください。

PostgreSQL はKerberosのバージョン5をサポートしています。Kerberos認証のサポートは PostgreSQL がビルドされた時点で開始されます。 詳細は 第15章 を参照してください。

PostgreSQL は通常の Kerberos サービスのように動作します。 サービスのプリンシパル名は servicename/hostname@realm です。

servicename krb_srvname 設定パラメータを使用したサーバ側によって設定されます。 さらに、クライアント側では krbsrvname 接続パラメータを使用します。( 項31.1.2 も参照してください。) インストール時のデフォルト postgres (ビルド時には ./configure - -with-krb-srvnam=whatever を使用しています)は、変更が可能です。 多くの環境では、このパラメータは変更する必要はないでしょう。しかしながら、同一ホスト内で複数の PostgreSQL をサポートするような場合には、必要となります。 いくつかのKerberosの実装では、異なるサービス名が必要になります。Microsoftアクティブディレクトリではサービス名は( POSTGRES )のように大文字にする必要があります。

hostname はサーバマシンの完全修飾されたホスト名です。 サービスプリンシパルのrealmはサーバマシンが提起したrealmです[訳注:プリンシパルとは大雑把に2つのものを指します。1つはサービスを受けるクライアントで、もう1つはサービスを提供するサーバアプリケーションです。どちらも、認証に関してはKerberosのKDCから見るとクライアントになります]。

クライアントのプリンシパルは第一の構成要素として PostgreSQL のデータベースユーザ名を所有しなければなりません。 例えば、 pguser name/otherstuff@realm です。 もう1つの方法として、プリンシパル名の第一の構成要素からデータベースユーザ名にマップするユーザ名マッピングを使用することもできます。 デフォルトではクライアントのrealmは PostgreSQL で検査されません。 相互のrealm認証が使用可能になっていてrealmを確認する必要がある場合は、 krb_realm パラメータを使用するか include_realm を使用可能にしてrealmを検査するためにユーザ名を使用してください。

サーバ鍵ファイルが PostgreSQL サーバアカウントによって読み込み可能(そしてできれば読み込み専用)であることを確認してください ( 項17.1 を参照してください)。 鍵ファイルの保存場所は krb_server_keyfile 設定パラメータで指定されます デフォルトは、 /usr/local/pgsql/etc/krb5.keytab (もしくはビルド時に sysconfdir で指定されたディレクトリ)です。

keytabファイルはKerberosのソフトウェアによって作成されます。詳細はKerberosのドキュメントを参照してください。 MIT互換のKerberos5実装の例を以下に示します。


kadmin% 

ank -randkey postgres/server.my.domain.org


kadmin% 

ktadd -k krb5.keytab postgres/server.my.domain.org

データベースに接続しようとしている時要求されるデータベースユーザ名に一致するプリンシパルのチケットを所有しているか確認してください。 例えば、データベースユーザ名 fred に対し、 fred@EXAMPLE.COM のプリンシパルは接続できるでしょう。 fred/users.example.com@EXAMPLE.COM のプリンシパルも許可するためには 項19.2 内に記述されているユーザ名マップを使用して下さい。

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

次の設定オプションは Kerberos のためにサポートされています。

map

システムとデータベースユーザ名の間のマッピングを許可します。 詳細は 項19.2 を参照してください。

include_realm

1 に設定されている場合は、認証されたユーザプリンシパルからのrealm名が、 ユーザ名マッピング( 項19.2 )で渡されるシステムユーザ名の中に含まれています。 これは複数realmからのユーザを扱う場合に便利です。

krb_realm

realmをユーザプリンシパル名に一致するように設定します。もしこのパラメータが設定されている場合は realmのユーザのみが受け付けられます。もしこれが設定されていない場合は、 どのようなrealmのユーザも接続可能で、ユーザ名マッピングが設定されていれば、どれでも影響を受けます。

krb_server_hostname

サービスプリンシパルのホスト名部分を設定します。これは krb_srvname と組み合わせて使用されますが、 完結したサービスプリンシパルを生成するために使用されます。つまり以下のようになります。 krb_srvname / krb_server_hostname @ REALM 設定されていない場合は、デフォルトではサーバのホスト名になっています。

19.3.6. Ident認証

ident認証方式は、クライアントのオペレーティングシステムのユーザ名をidentサーバから入手し、それを(オプションのユーザ名マップとともに)許可されているデータベースのユーザ名として使用します。 これはTCP/IP接続のみサポートされます。

注意: identが(TCP/IPではない)ローカル接続で指定されている場合、 ピア認証( 項19.3.7 を参照してください)が代わりに使用されます。

次の設定オプションは ident のためにサポートされています。

map

システムとデータベースユーザ名の間のマッピングを許可します。 詳細は 項19.2 を参照してください。

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

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

 

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

 
-- RFC 1413  

いくつかの身元特定サーバは、ユーザ名を(マシンの管理者のみが知っているキーで)暗号化して返すような非標準のオプションを持っています。 このオプションは、身元特定サーバと PostgreSQL とを一緒に使用する場合には、使用しては いけません 。 理由は PostgreSQL は、返された文字列を復号化して本当のユーザを決定するための手段を持っていないためです。

19.3.7. Peer認証

peer認証方式はカーネルからクライアント上のオペレーティングシステムのユーザ名を取得し、 それをデータベースユーザ名(オプションのユーザ名マップとともに)として使用することにより動作します。この方法はローカル接続でのみ使用可能です。

次の設定オプションは peer のためにサポートされています。

map

システムとデータベースのユーザ名のマッピングを許可します。詳細は 項19.2 を参照してください。

Peer認証はオペレーティングシステムが、 getpeereid() 関数、 SO_PEERCRED のソケットパラメータ、もしくは同じような仕組みを提供しているときにのみ使用可能です。現状では、 Linux Mac OS X を含む BSD 系、そして Solaris に含まれています。

19.3.8. LDAP認証

この認証方式は password と似ていますが、パスワード確認にLDAPを使用する点が異なります。 LDAPはユーザの名前とパスワードの組み合わせの検証のみに使用されます。 そのため、LDAPを使用して認証を行うようにする前に、ユーザはデータベースに存在しなければなりません。

LDAP認証は2つのモードで動作します。1つ目のモードでは、それは単なるバインド・モードを呼び出すものですが、 サーバは prefix user name suffix として区別された名前にバインドします。 一般的に、 prefix パラメータはActive Directory環境での cn= DOMAIN \ を特定するために使用されます。 suffix は、Active Directory環境ではない場合でのDNの残りの部分を特定するために使用されます。

2つ目のモードでは、それはsearch/bindモードを呼び出すもので、サーバは最初に ldapbinddn ldapbindpasswd で指定された、 固定されたユーザ名とパスワードを使用してLDAPディレクトリにバインドします。 それからデータベースにログインしようとしているユーザを検索します。 もしユーザとパスワードが指定されていなかった場合は、ディレクトリに対して匿名でバインドします。 検索は ldapbasedn のサブツリーまで行われ、 ldapsearchattribute で指定された属性に 正確に一致するかどうかまで行われます。 この検索において、一度ユーザが見つかるとサーバは切断して、クライアントで指定されたパスワードを使用して このユーザとして再度ディレクトリにバインドします。これはそのログインが正しいかどうかを検証するためです。 このモードはApache mod_authnz_ldap および pam_ldapのように他のソフトウェアと同じように、LDAP認証の仕組みで使用されるものと同じです。 この方法は、ユーザオブジェクトがディレクトリに配置されている場合に、かなりの柔軟性があります。 しかし、LDAPサーバへの2つの分離した接続が作成されます。

次の設定オプションは両方のモードで使用されます。

ldapserver

接続するLDAPサーバの名称もしくはIPアドレスの名称。空白で区切ることで複数のサーバを指定できます。

ldapport

LDAPサーバに接続するためのポート番号。もしポートが指定されていない場合は LDAPライブラリ内のデフォルトポート設定が使用されます。

ldaptls

1 に設定すると、PostgreSQLとLDAPサーバ間の接続にTLSによる暗号化を使用します。 これはLDAPサーバへのトラフィックのみを暗号化することに注意してください。— クライアントへの接続はSSLを使用しない限り暗号化されません。

以下のオプションは単純バインド・モードのみで使用されます。

ldapprefix

単純なバインド認証を行う場合のDNを生成する際にユーザ名の前に追加する文字列

ldapsuffix

単純なバインド認証を行う場合のDNを生成する際にユーザ名の前に追加する文字列

以下のオプションはsearch/bindモードのみで使用されます。

ldapbasedn

検索とバインドの認証を行う場合のユーザ名がログインするための検索を始めるためのDN

ldapbinddn

検索とバインドの認証を行う場合のディレクトリと検索をバインドするためのユーザのDN

ldapbindpasswd

検索とバインドの認証を行う場合のディレクトリと検索をバインドするためのユーザのパスワード

ldapsearchattribute

検索とバインドの認証を行う場合の検索時のユーザ名に対して一致させる属性。 属性が指定されない場合、属性 uid が使用されます。

ldapurl

RFC 4516 LDAP URL。これはその他いくつかのLDAPオプションをより簡潔、かつ一般的な形式で記述する別の方法です。 フォーマットは以下のようになっています。

ldap://

host

[:

port

]/

basedn

[?[

attribute

][?[

scope

]]]

scope base one ,、 sub のいずれかでなくてはならず、一般的には最後のものです。

非匿名バインド(non-anonymous bind)に対し、 ldapbinddn および ldapbindpasswd は個別のオプションとして指定されなければなりません。

暗号化されたLDAP接続を使用するには、 ldapurl に加え ldaptls オプションを使用しなければなりません。 ldaps URLの仕組み(直接SSL接続)はサポートされていません。

現在の所、LDAP URLはWindows上ではなく、OpenLDAPのみでサポートされています。

seartch/bindオプションと単純バインドに対するオプションの設定を混在させるのはエラーです。

以下に単純バインドLDAP設定の例を示します。

host ... ldap ldapserver=ldap.example.net ldapprefix="cn=" ldapsuffix=", dc=example, dc=net"

データベースのユーザ、 someuser からデータベースサーバに接続を要求された場合、PostgreSQLはDN cn=someuser, dc=example, dc=net およびクライアントから提供されたパスワードを用いてLDAPサーバにバインドを試みます。その接続が成功すればデータベースへのアクセスが認められます。

以下はsearch/bind設定の例です。

host ... ldap ldapserver=ldap.example.net ldapbasedn="dc=example, dc=net" ldapsearchattribute=uid

データベースユーザ someuser としてデータベースに接続するとき、PostgreSQLは( ldapbinddn が指定されていないので)匿名的にバインドを試み、指定されたベースDNの基で (uid=someuser) の検索を行います。あるエントリが見つかると、見つかった情報とクライアントから与えられたパスワードを用いて、その結果バインドを試みます。その二番目の接続が成功するとデータベースアクセスが認められます。

URLとして記述した同じsearch/bind設定の例です。

host ... ldap lapurl="ldap://ldap.example.net/dc=example,dc=net?uid?sub"

LDAPに対し認証をサポートする幾つかの他のソフトウェアは同じURLフォーマットを使用します。 従って、設定をより簡易に共有することができます。

ティップ: LDAPはDNの異なる構成要素を区別するため往々にしてコンマとスペースを使用します。 例で示されたように、LDAPオプションを設定する場合、二重引用符で括られたパラメータ値を使用することが必須となることがしばしば必須となります。

19.3.9. RADIUS Authentication

この認証方法は、RADIUSをパスワード検証として使用するという点を除いて password と似た動作をします。 RADIUSはユーザ名/パスワードの組のみを検証するために使用されます。 よってユーザはRADIUSが認証に使用される以前にデータベースにすでに存在していなければいけません。

RADIUS認証を使用する場合に、設定されたRADIUSサーバにアクセスリクエストメッセージが送信されます。 このリクエストは Authenticate Only の形式になり、 ユーザ名 , (暗号化された) パスワード NAS識別子 を含んでいます。 リクエストはサーバと共有している秘密を用いて暗号化されます。 RADIUSサーバは、このサーバに対して Access Accept もしくは Access Reject を返します。 RADIUSアカウントのサポートはありません。

RADIUSのために次の設定オプションがサポートされています。

radiusserver

接続するRADIUSサーバの名称もしくはIPアドレス。このパラメータは必要です。

radiussecret

RADIUSサーバとのやり取りに使用される共有の秘密。これはPostgreSQLとRADIUSサーバにおいて 厳密に同じ値にする必要があります。少なくとも16文字以上の文字列が推奨されます。このパラメータは必要です。

注意: PostgreSQL OpenSSL をサポートする場合に暗号化ベクター使用するときのみ 強力になります。他の場合にはRADIUSサーバへの伝送は難読化されているだけで、安全ではなく 必要な場合は外部のセキュリティ方法を適用すべきです。

radiusport

接続するRADIUSサーバのポート番号。もしポート番号が指定されていない場合は、デフォルトポートである 1812 が使用されます。

radiusidentifier

RADIUSリクエスト内で NAS Identifier として使用されている文字列。 ユーザがどのデータベースユーザに対して認証しようとしているか、RADIUSサーバにおいてポリシーを一致させるために何が使用されるか、 を識別するために、このパラメータは2番目のパラメータとして使用されます。 もし識別子が指定されていない場合は、デフォルトの postgresql が使用されます。

19.3.10. 証明書認証

この認証方法は、認証のためにSSLクライアント証明書を使用します。 よってこの方法は、SSL接続を使用します。 この認証方法を使用する際は、サーバはクライアントが有効な証明書を提供することを要求します。 パスワードのプロンプトはクライアントに送信されません。 証明書の cn (Common Name)属性は、要求されたデータベースユーザ名と比較されます。 もしそれらが一致した場合はログインが許可されます。ユーザ名マッピングは、 cn がデータベースユーザ名と異なるものであることを許可するために使用されます。

次の設定オプションはSSL証明書認証のためにサポートされています。

map

システムとデータベースユーザ名の間のマッピングを許可します。 詳細は 項19.2 を参照してください。

19.3.11. PAM認証

この認証方式は認証機構としてPAM(Pluggable Authentication Modules)を使用することを除いて password のように動作します。 デフォルトのPAMサービス名は postgresql です。 PAMはユーザ名/パスワードの組を承認するためだけに使用されます。 PAMについての詳細は Linux-PAM ページ を読んでください。

次の設定オプションはPAMのためにサポートされています。

pamservice

PAMサービス名。

注意: PAMが /etc/shadow を読み取るように設定されている場合は、PostgreSQLがルートユーザで起動されていないため、認証は失敗するでしょう。 しかしPAMがLDAPや他の認証方法を使用するように設定されている場合は、これは問題ではありません。


powered by SEO.CUG.NET