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

31.18. SSLサポート

PostgreSQL は、セキュリティを高めるためにクライアントサーバ間の通信を暗号化する SSL 接続の使用を元来サポートしています。 サーバ側の SSL 機能についての詳細は 項17.9 を参照してください。

libpq はシステム全体に対する OpenSSL 設定ファイルを読み込みます。 デフォルトでは、ファイル名は openssl.cnf で、 openssl version -d で報告されるディレクトリに格納されています。 このデフォルトは OPENSSL_CONF 環境変数に希望する設定ファイル名を設定することで変更することができます。

31.18.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 で変更することができます。

注意: より古いバージョンのPostgreSQLとの後方互換性のために、ルートCAファイルが存在する場合、 sslmode = require の動作は verify-ca の場合と同じになっています。 つまり、サーバ証明書がCAに対して検証されます。 この動作に依存することは勧めません。 また証明書の検証を必要とするアプリケーションは常に verify-ca または verify-full を使用すべきです。

31.18.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.18.3. 異なるモードで提供される保護

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

盗聴

クライアント・サーバ間のネットワークトラフィックを第三者が監視することができれば、(ユーザ名とパスワードを含め)双方の接続情報と通過するデータを読み取ることができます。 SSL はこれを防止するために暗号を使用します。

中間者攻撃( MITM

データがクライアント・サーバ間で渡されている時に、第三者がそのデータを変更できれば、サーバを装うことができ、従って たとえ暗号化されていても データを理解し変更することができます。 第三者はそこで、この攻撃を検出不可能にする接続情報とデータを元のサーバに送ることができます。 これを行う共通した媒介はDNSポイゾニングとアドレス乗っ取りを含み、それに従ってクライアントは意図したサーバではなく異なったサーバに誘導されます。 同時に、このことを成し遂げるいくつかの異なった攻撃も存在します。 SSL はクライアントに対しサーバを認証することで、この防止に証明書検証を使用します。

なりすまし

第三者が認定されたクライアントを装うことができれば、それはアクセスしてはならないデータに簡単にアクセス可能になります。 典型的にこれは心もとないパスワード管理から生じます。 SSL は有効な証明書の所持者のみサーバにアクセスできることを確実にすることで、この防止策としてクライアント証明書を使用します。

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

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

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

表 31-1. SSLモードの説明

sslmode 盗聴防止 MITM 防止 声明
disable いいえ いいえ セキュリティはどうでもよく、暗号化の負荷を払いたくない
allow たぶん いいえ セキュリティはどうでもよいが、サーバがそれを強く要求するのであれば暗号化のオーバヘッドを払ってもよい
prefer たぶん いいえ セキュリティはどうでもよいが、サーバがそれをサポートするのであれば暗号化のオーバヘッドを払ってもよい
require はい いいえ データを暗号化して欲しい。そしてオーバヘッドも受け入れる。サーバに接続する必要時に常にネットワークが確認してくれることを信用する
verify-ca はい CA の規定に 依存 データを暗号化して欲しい。そしてオーバヘッドも受け入れる。信頼するサーバに確実に接続したい
verify-full はい はい データを暗号化して欲しい。そしてオーバヘッドも受け入れる。信頼するサーバに接続すること、そのサーバが指定したものであることを確実にしたい

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

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

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

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

表 31-2. libpq/クライアントにおけるSSLファイルの使用方法

ファイル 内容 効果
~/.postgresql/postgresql.crt クライアント証明書 サーバにより要求されます
~/.postgresql/postgresql.key クライアントの秘密キー 所有者により送信されるクライアント証明書を証明します。証明書の所有者が信頼できることを意味していません。
~/.postgresql/root.crt 信頼できる認証局 サーバ証明書が信頼できる認証局により署名されたか検査します。
~/.postgresql/root.crl 認証局により失効された証明書 サーバ証明書はこのリストにあってはいけません

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

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

PQinitOpenSSL

アプリケーションがどのセキュリティライブラリを初期化するか選択することができます。

void PQinitOpenSSL(int do_ssl, int do_crypto);

do_ssl が非ゼロの時、 libpq は最初のデータベース接続を開始する以前に OpenSSL ライブラリを初期化します。 do_crypto が非ゼロの時、 libcrypto ライブラリが初期化されます。 デフォルトでは( PQinitOpenSSL が呼ばれない場合)、両方のライブラリが初期化されます。 SSLサポートがコンパイルされていない場合、この関数は存在しますが何もしません。

使用するアプリケーションが OpenSSL またはその基礎をなす libcrypto ライブラリのいずれかを使用し、そして初期化するのであれば、最初のデータベース接続開始以前に、適切なパラメータをゼロにしてこの関数を呼び出さなければ なりません 。 同時に、データベース接続開始前に初期化を行ったことの確認をしてください。

PQinitSSL

アプリケーションがどのセキュリティライブラリを初期化するか選択することができます。

void PQinitSSL(int do_ssl);

この関数は PQinitOpenSSL(do_ssl, do_ssl) と等価です。 OpenSSL および libcrypto の両方を初期化する、もしくは両方ともしないアプリケーションにとっては(この関数で)十分です。

PostgreSQL 8.0以降、 PQinitSSL は含まれていますが、 PQinitOpenSSL PostgreSQL 8.4で追加されました。 従って、旧バージョンの libpq で動かす必要があるアプリケーションでは PQinitSSL の方が好ましいかもしれません。


powered by SEO.CUG.NET