PostgreSQLは、TLSプロトコルを使用して、セキュリティを高めるためにクライアントサーバ間の通信を暗号化するSSL接続の使用を元来サポートしています。 サーバ側のSSL機能についての詳細は19.9を参照してください。
libpqはシステム全体に対するOpenSSL設定ファイルを読み込みます。
デフォルトでは、ファイル名はopenssl.cnf
で、openssl version -d
で報告されるディレクトリに格納されています。
このデフォルトはOPENSSL_CONF
環境変数に希望する設定ファイル名を設定することで変更することができます。
デフォルトではPostgreSQLはサーバ証明書の検証をまったく行いません。 これは、(例えば、DNSレコードを変更したり、もしくはサーバのIPアドレスを乗っ取ったりして)クライアントに知られずにサーバの身元をなりすませることを意味します。 なりすましを防止するには、クライアントは、トラストチェーン(chain of trust)を通じて、サーバの身元を検証できなければなりません。 トラストチェーンは、ルート(自己署名)認証局(CA)証明書をあるコンピュータに設置し、そのルート証明書によって署名されたリーフ証明書を他のコンピュータに設置することによって確立されます。 また、ルート証明書によって署名された「中間」証明書を使って、リーフ証明書に署名することによっても可能です。
クライアントがサーバの身元を検証するためには、ルート証明書をクライアントに設置し、そのルート証明書によって署名されたリーフ証明書をサーバに設置します。 サーバがクライアントの身元を検証するためには、ルート証明書をサーバに設置し、そのルート証明書によって署名されたリーフ証明書をクライアントに設置します。 一つ以上の中間証明書(通常リーフ証明書とともに格納されます)を使って、リーフ証明書をルート証明書につなげることもできます。
トラストチェーンがひとたび確立されれば、クライアントがサーバから送信されたリーフ証明書を検証する二つの方法があります。
パラメータsslmode
がverify-ca
に設定されている場合、libpqはクライアントに格納されたルート証明書までの証明書連鎖を検査することで、サーバが信用に足るかを検証します。
sslmode
がverify-full
に設定されていると、libpqは同時にサーバホスト名が証明書のそれと一致するかを検証します。
SSL接続はサーバ証明書が検証されない場合失敗します。
安全性に慎重を期するほとんどのサーバ環境ではverify-full
を推奨します。
verify-full
モードでは、ホスト名を証明書のサブジェクト別名(Subject Alternative Name(SAN))属性と、あるいはdNSName
タイプのサブジェクト別名がないときはコモンネーム属性とマッチさせます。
証明書の名前属性がアスタリスク(*
)で始まると、それはワイルドカードとして取り扱われ、ドット(.
)を除くすべての文字とマッチします。
これは、証明書がサブドメインとマッチしないことを意味します。
もし接続がホスト名ではなくIPアドレスを使用するのであれば、タイプiPAddress
またはdNSName
のSANに対してIPアドレスが照合されます(DNS検索は実行されません)。iPAddress
SANが存在せず、マッチングdNSName
SANが存在しない場合、ホストIPアドレスはコモンネーム属性に対して照合されます。
PostgreSQLの以前のバージョンとの後方互換性のために、ホストIPアドレスはRFC 6125とは異なる方法で検証されます。
ホストIPアドレスはDNsName
SANおよびIpAddress
SANに対して常に照合され、関連するSANが存在しない場合はCommon Name属性に対して照合できます。
サーバ証明書の検証を可能にするには、1つ以上のルート証明書を、ユーザのホームディレクトリの~/.postgresql/root.crt
ファイルに置かなければなりません。
(Microsoft Windowsの場合、このファイルの名前は%APPDATA%\postgresql\root.crt
です。)
サーバより送信された証明書連鎖から、クライアントに格納されたルート証明書にリンクするために(中間証明書が)必要なら、中間証明書もそのファイルに追加する必要があります。
~/.postgresql/root.crl
ファイル(Microsoft Windowsでは%APPDATA%\postgresql\root.crl
)が存在する場合、証明書失効リスト(CRL)の項目もまた検査されます。
ルート証明書ファイルとCRLの格納場所を接続パラメータsslrootcert
とsslcrl
、もしくは環境変数PGSSLROOTCERT
とPGSSLCRL
で変更することができます。
sslcrldir
または環境変数PGSSLCRLDIR
を使用して、CRLファイルを含むディレクトリを指定することもできます。
より古いバージョンのPostgreSQLとの後方互換性のために、ルートCAファイルが存在する場合、sslmode
=require
の動作はverify-ca
の場合と同じになっています。
つまり、サーバ証明書がCAに対して検証されます。
この動作に依存することは勧めません。
また証明書の検証を必要とするアプリケーションは常にverify-ca
またはverify-full
を使用すべきです。
サーバが、クライアントのリーフ証明書を要求することによってクライアントの身元を検証しようとする場合、libpqはユーザのホームディレクトリにある~/.postgresql/postgresql.crt
ファイルに格納された証明書を送信します。
証明書は、サーバが信頼するルート証明書につながらなければなりません。
対応する~/.postgresql/postgresql.key
秘密キーファイルも存在しなければなりません。
秘密キーファイルは他者やグループからのアクセスを許可してはいけません。
Microsoft Windowsでは、このファイルの名前はそれぞれ%APPDATA%\postgresql\postgresql.crt
と%APPDATA%\postgresql\postgresql.key
です。
証明書とキーファイルの格納場所はsslcert
およびsslkey
接続パラメータ、またはPGSSLCERT
およびPGSSLKEY
環境変数で上書きされます。
Unixシステムにおいて、秘密鍵ファイル権限はグループ、他者へのアクセスをすべて拒否しなければなりません。
これはchmod 0600~/.postgresql/postgresql.key
といったコマンドによって行います。
あるいは、このファイルをrootが所有し、グループの読み取りアクセス権(つまり0640
のアクセス権)を持つこともできます。
このセットアップは、証明書と鍵ファイルがオペレーティングシステムによって管理されているインストールを対象としています。
libpqのユーザは、これらの証明書と鍵ファイルへのアクセス権を持つグループのメンバになる必要があります。
(Microsoft Windowsにおいては、%APPDATA%\postgresql
ディレクトリが安全であると考えられるため、ファイルの権限の検査は行われません。)
postgresql.crt
中の最初の証明書は、クライアント証明書でなければなりません。
クライアントの秘密鍵と一致していなければならないからです。
オプションで、ファイルに「中間」証明書を追加することができます。
そうすることによって、サーバ上に中間証明書(ssl_ca_file)の格納が不要になります。
証明書とキーはPEMまたはASN.1 DER形式です。
キーは平文テキストで、あるいは、OpenSSLで対応しているAES-128など任意のアルゴリズムを使ってパスフレーズで暗号化して、格納できます。
キーが暗号化されて格納された場合、パスフレーズはsslpassword接続オプションで供給してもよいです。
暗号化されたキーが供給されて、かつ、sslpassword
が無いか空欄の場合、TTYが利用可能であればパスワードはOpenSSLによりEnter PEM pass phrase:
プロンプトで対話的に入力が要求されます。
アプリケーションはクライアント証明書のプロンプトとsslpassword
パラメータの操作を、自身のキーパスワードコールバックを供給することで置き換えできます。
PQsetSSLKeyPassHook_OpenSSL
を参照してください。
証明書の作成手順については、19.9.5をご覧ください。
sslmode
パラメータ値を変更することで、異なったレベルの保護を提供します。
SSLは以下の3種類の攻撃に対する保護を提供することができます。
クライアント・サーバ間のネットワークトラフィックを第三者が監視することができれば、(ユーザ名とパスワードを含め)双方の接続情報と通過するデータを読み取ることができます。 SSLはこれを防止するために暗号を使用します。
データがクライアント・サーバ間で渡されている時に、第三者がそのデータを変更できれば、サーバを装うことができ、従ってたとえ暗号化されていてもデータを理解し変更することができます。 第三者はそこで、この攻撃を検出不可能にする接続情報とデータを元のサーバに送ることができます。 これを行う共通した媒介はDNSポイズニングとアドレス乗っ取りを含み、それに従ってクライアントは意図したサーバではなく異なったサーバに誘導されます。 同時に、このことを成し遂げるいくつかの異なった攻撃も存在します。 SSLはクライアントに対しサーバを認証することで、この防止に証明書検証を使用します。
第三者が認定されたクライアントを装うことができれば、それはアクセスしてはならないデータに簡単にアクセス可能になります。 典型的にこれは心もとないパスワード管理から生じます。 SSLは有効な証明書の所持者のみサーバにアクセスできることを確実にすることで、この防止策としてクライアント証明書を使用します。
SSLで信頼できるとされる接続では、SSLの使用を接続確立前にクライアントとサーバの双方において設定されなければなりません。
サーバのみに構成されると、クライアントはサーバが高度なセキュリティを必要とすることが判る以前に、(例えばパスワードのような)機密事項を扱う情報を結局送ることになります。
libpqにおいて、sslmode
パラメータをverify-full
またはverify-ca
に設定し、そして対象を検証するためルート証明書をシステムに提供することで、安全な接続を確実に行うことができます。
これは暗号化されたweb閲覧に対するhttps
URLの使用とよく似ています。
一度サーバが認証されると、クライアントは機密事項を扱うデータを送ることができます。 この意味は、これまでクライアントは認証に証明書が使われているかどうかを知る必要がなく、サーバ構成においてのみこのことを指定しても安全だと言うことです。
すべてのSSLオプションでは暗号化の形式と鍵交換といったオーバーヘッドがかかります。
このため性能と安全性との間で決定されるべきトレードオフがあります。
表 34.1は異なるsslmode
値が防御する危険性と、安全性とオーバーヘッドに対する声明を示したものです。
表34.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
です。
表で示したように、これはセキュリティの視点では意味がなく、可能であれば性能上のオーバーヘッドを保証するだけです。
これは後方互換性を提供するためのみにデフォルトとなっているもので、安全性確保の観点からは推奨されません。
表 34.2にクライアントにおけるSSL設定に関連するファイルをまとめます。
表34.2 libpq/クライアントにおけるSSLファイルの使用方法
ファイル | 内容 | 効果 |
---|---|---|
~/.postgresql/postgresql.crt | クライアント証明書 | サーバにより要求されます |
~/.postgresql/postgresql.key | クライアントの秘密キー | 所有者により送信されるクライアント証明書を証明します。証明書の所有者が信頼できることを意味していません。 |
~/.postgresql/root.crt | 信頼できる認証局 | サーバ証明書が信頼できる認証局により署名されたか検査します。 |
~/.postgresql/root.crl | 認証局により失効された証明書 | サーバ証明書はこのリストにあってはいけません |
使用するアプリケーションがlibssl
とlibcrypto
の両方またはいずれか一方のライブラリを初期化し、libpqがSSLサポート付きで構築された場合、libssl
とlibcrypto
の両方またはいずれか一方のライブラリはアプリケーションによって初期化されたことをlibpqに伝えるためPQinitOpenSSL
を呼び出さなければなりません。
これにより、libpqはこれらのライブラリを初期化しなくなります。
ただし、OpenSSLバージョン1.1.0以降を使用している場合は、重複の初期化に問題がなくなるため、これは不要です。
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
の方が好ましいかもしれません。