PostgreSQL 9.0.4文書 | ||||
---|---|---|---|---|
前のページ | 巻戻し | 第 19章クライアント認証 | 早送り | 次のページ |
以下の小節では、認証方式について詳細に説明します。
trust認証が指定されるとPostgreSQLは、サーバに接続できる全ての人に対して (データベーススーパーユーザさえも)その人が指定する任意のデータベースユーザ名としてのアクセス権限が付与されていると想定します。 当然ながらdatabaseとuser列にある制限は適用されます。 この方式はサーバに接続する際に適切なオペレーティングシステムレベルの保護が掛けられている場合にのみ使用すべきです。
trust認証はユーザが1人のみのワークステーション上でローカル接続を行う場合は適切であると同時に非常に便利です。 複数ユーザが存在するマシン上では一般的に適切ではありません。 とは言っても、ファイルシステムの許可属性を使ってサーバのUnixドメインソケットファイルへのアクセスを制限すればtrust認証を複数ユーザのマシン上で使用することも可能です。 その方法は、項18.3に記載されているようにunix_socket_permissions(およびunix_socket_groupパラメータの可能性もあります)パラメータを設定します。 もしくは、unix_socket_directory設定パラメータでソケットファイルをそれに相応しく制限されているディレクトリにします。
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認証を用いる理由はほとんど見当たりません。
パスワードをベースにした認証方式には 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 USERを使って管理できます。 もしユーザに対してパスワードが設定されない場合、格納されるパスワードはNULLとなり、そのユーザのパスワード認証は常に失敗します。
GSSAPIは、RFC 2743で定義されている安全な認証のための業界標準のプロトコルです。 PostgreSQLは、RFC 1964によりKerberos認証と共にGSSAPIをサポートします。 GSSAPIは、GSSAPIをサポートしているシステムに対して自動認証(シングルサインオン)を提供します。 認証自体は安全ですが、データベース接続を通じて送信されるデータは、SSLが使用されていない場合は平文となります。
GSSAPIサポートは、PostgreSQLが構築されたときに使用可能となります。詳細は、第15章を参照してください。
次の設定オプションはGSSAPIのためにサポートされています。
1に設定されている場合は、認証されたユーザプリンシパルからのレルム名が、 ユーザ名マッピング(項19.2)で渡されるシステムユーザ名の中に含まれています。 これは複数レルムからのユーザを扱う場合に便利です。
システムとデータベースの間のマッピングを許可します。詳細は項19.2を参照してください。 Kerberosプリンシパルに対してはusername/hostbased@EXAMPLE.COM、もしinclude_realmが 無効になっている場合はマッピングに対して使用されるユーザ名はusername/hostbased、 include_realmが有効になっている場合はusername/hostbased@EXAMPLE.COMです。
realmをユーザプリンシパル名に一致するように設定します。もしこのパラメータが設定されている場合は realmのユーザのみが受け付けられます。もしこれが設定されていない場合は、 どのようなrealmのユーザも接続可能で、ユーザ名マッピングが設定されていれば、どれでも影響を受けます。
SSPIは、シングルサインオンで安全な認証を行うためのWindowsの技術です。 PostgreSQLは、negotiateモードにおいてSSPIを使用します。 これは、可能な場合はKerberosを使用し、他の場合については自動的にNTLMを使用することを意味しています。 SSPI認証は、サーバ、クライアントが共にWindows上で稼動しているときにのみ動作します。
Kerberos認証を使用しているとき、 SSPIは、GSSAPIと同じように動作します。 詳細は項19.3.3を参照してください。
次の設定オプションはSSAPIのためにサポートされています。
1に設定されている場合は、認証されたユーザプリンシパルからのrealm名が、 ユーザ名マッピング(項19.2)で渡されるシステムユーザ名の中に含まれています。 これは複数realmからのユーザを扱う場合に便利です。
システムとデータベースユーザ名の間のマッピングを許可します。 詳細は項19.2を参照してください。
realmをユーザプリンシパル名に一致するように設定します。もしこのパラメータが設定されている場合は realmのユーザのみが受け付けられます。もしこれが設定されていない場合は、 どのようなrealmのユーザも接続可能で、ユーザ名マッピングが設定されていれば、どれでも影響を受けます。
注意: ネイティブのKerberos認証は、推奨されず互換性のためのみに使用されるべきです。新規に更新されたインストールは業界標準のGSSAPI認証を使用することを推奨しています。(詳細は項19.3.3を参照してください)
Kerberosは業界標準の安全な認証システムで、公開ネットワークにまたがった分散処理に適しています。 Kerberosシステムの説明はこの文書の範囲外で、概ねとても(強力ですが)複雑なものと言えます。 KerberosFAQあるいはMIT Kerberosページが探索を開始するにはお勧めです。 Kerberosのソースコード配布物はいくつか存在します。 Kerberosは安全な認証を提供しますが、ネットワーク越しに渡される問い合わせやデータの暗号化を行いません。 このためにはSSLを使用してください。
PostgreSQLはKerberosのバージョン5をサポートしています。Kerberos認証のサポートはPostgreSQLがビルドされた時点で開始されます。 詳細は第15章を参照してください。
PostgreSQLは通常の Kerberos サービスのように動作します。 サービスのプリンシパル名はservicename/hostname@realmです。
servicenameはkrb_srvname設定パラメータを使用したサーバ側によって設定されます。 さらに、クライアント側ではkrbsrvname接続パラメータを使用します。(項31.1も参照してください。) インストール時のデフォルトpostgres(ビルド時には./configure 7 7with-krb-srvnam=whateverを使用しています)は、変更が可能です。 多くの環境では、このパラメータは変更する必要はないでしょう。しかしながら、同一ホスト内で複数のPostgreSQLをサポートするような場合には、必要となります。 いくつかのKerberosの実装では、異なるサービス名が必要になります。Microsoftアクティブディレクトリではサービス名は(POSTGRES)のように大文字にする必要があります。
hostnameはサーバマシンの完全修飾されたホスト名です。 サービスプリンシパルのrealmはサーバマシンが提起したrealmです[訳注:プリンシパルとは大雑把に2つのものを指します。1つはサービスを受けるクライアントで、もう1つはサービスを提供するサーバアプリケーションです。どちらも、認証に関してはKerberosのKDCから見るとクライアントになります]。
クライアントのプリンシパルは第一の構成要素としてPostgreSQLのデータベースユーザ名を所有しなければなりません。 例えば、pgusername/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_krbとmod_perlを使うのであればmod_perlスクリプトでAuthType KerberosV5SaveCredentialsが使用可能です。 この方法により追加のパスワードを必要とせず、 Webを通して安全なデータベースアクセスができます。
次の設定オプションはKerberosのためにサポートされています。
システムとデータベースユーザ名の間のマッピングを許可します。 詳細は項19.2を参照してください。
1に設定されている場合は、認証されたユーザプリンシパルからのrealm名が、 ユーザ名マッピング(項19.2)で渡されるシステムユーザ名の中に含まれています。 これは複数realmからのユーザを扱う場合に便利です。
realmをユーザプリンシパル名に一致するように設定します。もしこのパラメータが設定されている場合は realmのユーザのみが受け付けられます。もしこれが設定されていない場合は、 どのようなrealmのユーザも接続可能で、ユーザ名マッピングが設定されていれば、どれでも影響を受けます。
サービスプリンシパルのホスト名部分を設定します。これはkrb_srvnameと組み合わせて使用されますが、 完結したサービスプリンシパルを生成するために使用されます。つまり以下のようになります。 krb_srvname/krb_server_hostname@REALM 設定されていない場合は、デフォルトではサーバのホスト名になっています。
ident認証方式は、クライアントのオペレーティングシステムのユーザ名を入手し、それを(オプションのユーザ名マップとともに)許可されているデータベースのユーザ名として使用します。 クライアントのユーザ名の決定はセキュリティの重大なポイントであり、下記のように接続の形式によって異なる働きをします。
次の設定オプションはidentのためにサポートされています。
システムとデータベースユーザ名の間のマッピングを許可します。 詳細は項19.2を参照してください。
"身元特定(Identification)プロトコル"についてはRFC 1413で説明されています。 事実上全てのUnix系のオペレーティングシステムの配布には、デフォルトでTCPポート113を監視するidentサーバが付属しています。 identサーバの基本的な機能は"どのユーザがポートXからの接続を開始し、自分のポートYへの接続を初期化したのか?"というような質問に答えることです。 PostgreSQLは物理的な接続が確立された時にXとYの両方を認識するので、接続するクライアントのホスト上のidentサーバに応答指令信号を送ることができ、理論的には与えられたどの接続にもオペレーティングシステムユーザを決定できます。
この手続きの欠点は、クライアントの正直さに頼るところが大きいということです。 もしクライアントマシンが信用されない、もしくは危険に晒されている場合、攻撃者はポート113上でほぼどんなプログラムでも実行することができ、どのユーザ名でも好きに選んで返すことができます。 したがってこの認証方式は、各々のクライアントマシンが厳格な管理下にあり、データベースとシステム管理者が密接に連絡を取り合って動作している、外界から閉ざされたネットワークにのみ適していると言えます。 言い換えると、identサーバが稼働しているマシンを信用しなければなりません。 次の警告に注意してください。
身元特定プロトコルは、認証、あるいはアクセス管理プロトコルには意図されていません。 | ||
--RFC 1413 |
いくつかの身元特定サーバは、ユーザ名を(マシンの管理者のみが知っているキーで)暗号化して返すような非標準のオプションを持っています。 このオプションは、身元特定サーバとPostgreSQLとを一緒に使用する場合には、使用してはいけません。 理由はPostgreSQLは、返された文字列を復号化して本当のユーザを決定するための手段を持っていないためです。
UnixドメインソケットについてSO_PEERCRED要求をサポートしているシステム(現時点ではLinux、FreeBSD、NetBSD、OpenBSD、BSD/OS、およびSolaris)上では、ローカル接続に対してもident認証を適用できます。 PostgreSQLは、接続したクライアントプロセスのオペレーティングシステムのユーザ名を見つけ出すためにSO_PEERCREDを使用します。 この場合、ident認証使用による危険はありません。実際、このようなシステム上のローカル接続では推奨される方法です。
SO_PEERCRED要求のないシステム上ではTCP/IP接続に対してのみident認証が使えます。 使ってみるにはlocalhostアドレス127.0.0.1を指定してこのアドレスに接続してください。 この方法の信頼性は、ローカルなidentサーバが信頼できる範囲までです。
この認証方式はpasswordと似ていますが、パスワード確認にLDAPを使用する点が異なります。 LDAPはユーザの名前とパスワードの組み合わせの検証のみに使用されます。 そのため、LDAPを使用して認証を行うようにする前に、ユーザはデータベースに存在しなければなりません。
LDAP認証は2つのモードで動作します。1つ目のモードでは サーバはprefix username suffixとして区別された名前にバインドします。 一般的に、prefixパラメータはActive Directory環境でのcn=やDOMAIN\を特定するために使用されます。 suffixは、Active Directory環境ではない場合でのDNの残りの部分を特定するために使用されます。
2つ目のモードでは、サーバは最初にldapbinduserとldapbinddnで指定された、 固定されたユーザ名とパスワードを使用してLDAPディレクトリにバインドします。 それからデータベースにログインしようとしているユーザを検索します。 もしユーザとパスワードが指定されていなかった場合は、ディレクトリに対して匿名でバインドします。 検索はldapbasednのサブツリーまで行われ、ldapsearchattributeで指定された属性に 正確に一致するかどうかまで行われます。 もし属性が指定されていない場合は、uid属性が使用されます。 この検索において、一度ユーザが見つかるとサーバは切断して、クライアントで指定されたパスワードを使用して このユーザとして再度ディレクトリにバインドします。これはログインが正しいかどうかを確かめるためです。 この方法は、ユーザオブジェクトがディレクトリに配置されている場合に、かなりの柔軟性があります。 しかし、LDAPサーバへの2つの分離した接続が作成されます。
次の設定オプションはLDAPのためにサポートされています。
接続するLDAPサーバの名称もしくはIP
LDAPサーバに接続するためのポート番号。もしポートが指定されていない場合は LDAPライブラリ内のデフォルトポート設定が使用されます。
1に設定すると、PostgreSQLとLDAPサーバ間の接続にTLSによる暗号化を使用します。 これはLDAPサーバへのトラフィックのみを暗号化することに注意してください。— クライアントへの接続はSSLを使用しない限り暗号化されません。
単純なバインド認証を行う場合のDNを生成する際にユーザ名の前に追加する文字列
単純なバインド認証を行う場合のDNを生成する際にユーザ名の前に追加する文字列
検索とバインドの認証を行う場合のユーザ名がログインするための検索を始めるためのDN
検索とバインドの認証を行う場合のディレクトリと検索をバインドするためのユーザのDN
検索とバインドの認証を行う場合のディレクトリと検索をバインドするためのユーザのパスワード
検索とバインドの認証を行う場合の検索時のユーザ名に対して一致させる属性
注意: LDAPは、DNの異なる部分を分けるのにしばしばカンマと空白を使用します。そのため LDAPオプションを設定する際に2重引用符パラメータ値を使用する必要があります。 例を以下に示します。
ldapserver=ldap.example.net ldapprefix="cn=" ldapsuffix=", dc=example, dc=net"
この認証方法は、RADIUSをパスワード検証として使用するという点を除いてpasswordと似た動作をします。 RADIUSはユーザ名/パスワードの組のみを検証するために使用されます。 よってユーザはRADIUSが認証に使用される以前にデータベースにすでに存在していなければいけません。
RADIUS認証を使用する場合に、アクセスリクエストメッセージは設定されたRADIUSサーバに送信されます。 このリクエストはAuthenticate Onlyという種類のものであり、 user name、(暗号化済み)passwordおよびNAS Identifier用のパラメータを含みます。 このリクエストはサーバと共有している秘密を使用して暗号化されます。 RADIUSサーバは、Access AcceptもしくはAccess Rejectという応答をサーバに返します。 RADIUS課金のサポートはありません。
RADIUSのために次の設定オプションがサポートされています。
接続するRADIUSサーバの名称もしくはIPアドレス。このパラメータは必要です。
RADIUSサーバとのやり取りに使用される共有の秘密。これはPostgreSQLとRADIUSサーバにおいて 厳密に同じ値にする必要があります。少なくとも16文字以上の文字列が推奨されます。このパラメータは必要です。
注意: OpenSSLサポート付きでPostgreSQLを構築している場合、使用される暗号化ベクタは暗号として強力です。 他の場合にはRADIUSサーバへの伝送は難読化されているだけで、安全ではなく必要な場合は外部のセキュリティ方法を適用すべきです。
接続するRADIUSサーバのポート番号。もしポート番号が指定されていない場合は、デフォルトポートである1812が使用されます。
RADIUSリクエスト内でNAS Identifierとして使用されている文字列。 ユーザがどのデータベースユーザに対して認証しようとしているか、RADIUSサーバにおいてポリシーを一致させるために何が使用されるか、 を識別するために、このパラメータは2番目のパラメータとして使用されます。 もし識別子が指定されていない場合は、デフォルトのpostgresqlが使用されます。
この認証方法は、認証のためにSSLクライアント証明書を使用します。 よってこの方法は、SSL接続を使用します。 この認証方法を使用する際は、サーバはクライアントが有効な証明書を提供することを要求します。 パスワードのプロンプトはクライアントに送信されません。 証明書のcn(Common Name)属性は、要求されたデータベースユーザ名と比較されます。 もしそれらが一致した場合はログインが許可されます。ユーザ名マッピングは、cnがデータベースユーザ名と異なるものであることを許可するために使用されます。
次の設定オプションはSSL証明書認証のためにサポートされています。
システムとデータベースユーザ名の間のマッピングを許可します。 詳細は項19.2を参照してください。
この認証方式は認証機構としてPAM(Pluggable Authentication Modules)を使用することを除いてpasswordのように動作します。 デフォルトのPAMサービス名はpostgresqlです。 PAMはユーザ名/パスワードの組を承認するためだけに使用されます。 PAMについての詳細はLinux-PAMページとSolaris PAMページを読んでください。
次の設定オプションはPAMのためにサポートされています。
PAMサービス名。
注意: PAMが/etc/shadowを読み取るように設定されている場合は、PostgreSQLがルートユーザで起動されていないため、認証は失敗するでしょう。 しかしPAMがLDAPや他の認証方法を使用するように設定されている場合は、これは問題ではありません。