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