31.17. SSLサポート

31.17.1. サーバ証明書のクライアント検証

デフォルトではPostgreSQLはサーバ証明書の検証をまったく行いません。 これは、クライアントに知られずにサーバの属性をなりすます（例えば、DNSレコードを変更したり、もしくはサーバのIPアドレスを接収したりして）ことができることを意味します。 なりすましを防止するにはSSL証明書検証が使用されなければなりません。

パラメータsslmodeがverify-caに設定されている場合、libpqは信頼される認証局(CA)までの証明書連鎖を検査することで、サーバが信用に足るかを検証します。 sslmodeがverify-fullに設定されていると、libpqは同時にサーバホスト名が証明書のそれと一致するかを検証します。 SSL接続はサーバ証明書が検証されない場合失敗します。 安全性に慎重を期するほとんどのサーバ環境ではverify-fullを推奨します。

verify-fullモードでは証明書のcn（コモンネーム）属性はホスト名と一致させられます。 cn属性がアスタリスク（*）で始まると、それはワイルドカードとして取り扱われ、ドット（.）を除くすべての文字と一致します。 これは、証明書がサブドメインと一致しないことを意味します。 もし接続がホスト名ではなくIPアドレスを使用するのであれば、（いかなるDNS検索もせず）IPアドレスが一致させられます。

サーバ証明書の検証を可能にするには、1つ以上の信頼するCAの証明書を、ユーザのホームディレクトリの~/.postgresql/root.crtファイルに置かれなければなりません。 （Microsoft Windowsの場合、このファイルの名前は%APPDATA%\postgresql\root.crtです。）

~/.postgresql/root.crlファイル（Microsoft Windowsでは%APPDATA%\postgresql\root.crl）が存在する場合、証明書失効リスト（CRL）の項目もまた検査されます。

ルート証明書ファイルとCRLの格納場所を接続パラメータsslrootcertとsslcrl、もしくは環境変数PGSSLROOTCERTとPGSSLCRLで変更することができます。

31.17.2. クライアント証明書

サーバが信頼できるクライアント証明書を要求する場合、libpqはユーザのホームディレクトリにある~/.postgresql/postgresql.crtファイルに格納された証明書を送信します。 証明書はサーバで信頼された認証局（CA）のいずれかで署名されなければなりません。 対応する~/.postgresql/postgresql.key秘密キーファイルも存在しなければなりません。 秘密キーファイルは他者やグループからのアクセスを許可してはいけません。 chmod 0600 ~/.postgresql/postgresql.keyコマンドでこれを実現してください。 Microsoft Windowsでは、このファイルの名前はそれぞれ%APPDATA%\postgresql\postgresql.crtと%APPDATA%\postgresql\postgresql.keyであり、このディレクトリは安全であると想定されますので、特別な権限検査は行われません。 証明書とキーファイルの格納場所はsslcertおよびsslkey接続パラメータ、またはPGSSLCERTおよびPGSSLKEY環境変数で上書きされます。

クライアント証明書が、サーバにより直接信頼された認証局ではなく、"中間"証明局で署名されている場合があります。 こうした証明書を使用するためには、署名した認証局の証明書とその親の認証局の証明書をサーバにより信頼される"ルート"認証局までpostgresql.crtファイルに追加してください。 postgresql.crtに複数の証明書を含める時、すべての場合においてルート証明書を含めなければなりません。

root.crtには、サーバ証明書の署名に関して信頼できるとみなされる、最上位のCAが列挙されていることに注意してください。 原理的にはクライアント証明書を署名するCAを列挙する必要はありませんが、ほとんどの場合において、そのCAは同時にサーバ証明書に対しても信頼されています。

31.17.3. 異なるモードで提供される保護

sslmodeパラメータ値を変更することで、異なったレベルの保護を提供します。 SSLは以下の３種類の攻撃に対する保護を提供することができます。

信頼できるとされる接続では、SSLの使用を接続確立前にクライアントとサーバの双方において設定されなければなりません。 サーバのみに構成されると、クライアントはサーバが高度なセキュリティを必要とすることが判る以前に、（例えばパスワードのような）機密事項を扱う情報を結局送ることになります。 libpqにおいて、sslmodeパラメータをverify-fullまたはverify-caに設定し、そして対象を検証するためルート証明書をシステムに提供することで、安全な接続を確実に行うことができます。 これは暗号化されたweb閲覧に対するhttps URLの使用とよく似ています。

一度サーバが認証されると、クライアントは機密事項を扱うデータを送ることができます。 この意味は、これまでクライアントは認証に証明書が使われているかどうかを知る必要がなく、サーバ構成においてのみこのことを指定しても安全だと言うことです。

すべてのSSLオプションでは暗号化の形式と鍵交換といったオーバヘッドがかかります。 このため性能と安全性との間で決定されるべきトレードオフがあります。 表31-1は異なるsslmode値が対象を防御するかの危険性と、安全性とオーバヘッドに対する声明を示したものです。

verify-caとverify-fullの差異はルートCAの規定に依存します。 公的なCAが使用されるとき、verify-caはそのCAで他の誰かが登録したかもしれないサーバへの接続を許可します。 この場合、verify-fullが常に使用されなければなりません。 独自CAが使用されるとき、または自己署名証明書であったとしてもverify-caは十分な防御策を提供します。

sslmodeのデフォルト値はpreferです。 表で示したように、これはセキュリティの視点では意味がなく、可能であれば性能上のオーバヘッドを保証するだけです。 これは後方互換性を提供するためのみにデフォルトとなっているもので、安全性確保の観点からは推奨されません。

31.17.4. SSLクライアントファイル使用法

表31-2にクライアントにおけるSSL設定に関連するファイルをまとめます。

31.17.5. SSLライブラリの初期化

使用するアプリケーションがlibsslとlibcryptoの両方またはいずれか一方のライブラリを初期化し、libpqがSSLサポート付きで構築された場合、libsslとlibcryptoの両方またはいずれか一方のライブラリはアプリケーションによって初期化されたことをlibpqに伝えるためPQinitOpenSSLを呼び出さなければなりません。 これにより、libpqはこれらのライブラリを初期化しなくなります。 SSL APIの詳細はhttp://h71000.www7.hp.com/doc/83final/BA554_90007/ch04.htmlを参照してください。