他のバージョンの文書 11 | 10 | 9.6 | 9.5 | 9.4 | 9.3 | 9.2 | 9.1 | 9.0 | 8.4 | 8.3 | 8.2 | 8.1 | 8.0 | 7.4 | 7.3 | 7.2

18.9. SSLによる安全なTCP/IP接続

PostgreSQLは標準でSSL接続をサポートし、クライアント/サーバの通信がさらに安全になるよう暗号化します。 そのためにはOpenSSLがクライアントとサーバシステムの両方にインストールされ、構築時にPostgreSQLにおけるそのサポートが有効になっている必要があります(第16章を参照してください)。

SSLサポートを有効にしてコンパイルされた場合、PostgreSQLサーバは、postgresql.confにおいてsslパラメータをonにすることで、SSLサポートを有効にして起動することができます。 サーバは同じTCPポートで通常の接続とSSL接続の両方を待ち受け、クライアントとの接続にSSLを使用するかどうかを調停します。 デフォルトでは、これはクライアント側の選択肢です。 一部またはすべての接続でSSLの使用を必要とさせるためのサーバ側の設定方法に関しては20.1を参照してください。

PostgreSQLは、システム全体用のOpenSSL設定ファイルを読み取ります。 デフォルトでは、このファイルの名前はopenssl.cnfであり、openssl version -dで報告されるディレクトリに存在します。 このデフォルトは、環境変数OPENSSL_CONFを希望する設定ファイルの名前に設定することにより変更可能です。

OpenSSLは、強度が異なる、多くの暗号化および認証用のアルゴリズムをサポートします。 暗号の一覧はOpenSSL設定ファイル内で指定することができますが、postgresql.conf内のssl_ciphersを変更することで、データベースサーバで使用される暗号を指定することができます。

注記

NULL-SHAまたはNULL-MD5暗号を使用して暗号化のオーバーヘッドなしで認証を行うことが可能です。 しかし、中間者はクライアントサーバ間の通信を読み取り中継することができます。 また、暗号化のオーバーヘッドは認証のオーバーヘッドと比べると最小です。 こうした理由によりNULL暗号は推奨しません。

SSLモードで起動するには、サーバ証明書と秘密鍵を含むファイルが存在していなければなりません。 デフォルトでは、これらのファイルはserver.crtおよびserver.keyという名前で、それぞれがサーバのデータディレクトリに存在していることが想定されていますが、設定パラメータのssl_cert_filessl_key_fileによって他の名前、他の場所を指定することもできます。

Unixシステムでは、server.keyの権限は所有者以外からのアクセスを許可してはなりません。 これはchmod 0600 server.keyというコマンドで実現できます。 あるいは、このファイルの所有者をrootにして、グループに読み取りアクセス権を与える(つまり、パーミッションを0640にする)ということもできます。 この設定は、証明書と鍵ファイルがオペレーティングシステムによって管理されるインストレーションのためのものです。 PostgreSQLサーバを実行するユーザは、証明書と鍵ファイルにアクセス権のあるグループのメンバーにする必要があります。

秘密鍵がパスフレーズで保護されている場合、サーバはパスフレーズの入力を促し、入力されるまでは起動しません。 パスフレーズを使用すると、サーバを再起動せずにサーバのSSL設定を変更する機能も無効になります。 さらに、パスフレーズで保護された秘密鍵は、Windowsではまったく使用できません。

server.crtの最初の証明書は、サーバ証明書になり、秘密鍵とマッチしなければなりません。 中間認証局の証明書をファイルに追加することもできます。 これにより、ルートと中間証明書がv3_ca拡張により作成されていることが前提になりますが、中間証明書をクライアントに保存する必要が無くなります。 これは、中間証明書の有効期限の扱いをより簡単にします。

server.crtにルート証明書を追加する必要はありません。 代わりに、クライアントはサーバ証明書のチェーンを持つルート証明書を持っていなければなりません。

18.9.1. クライアント証明書の使用

信頼できる証明書をクライアントに要求するには、信頼するルート認証局(CA)の証明書をデータディレクトリ内のファイルに置き、postgresql.confssl_ca_fileパラメータをroot.crtに設定し、認証オプションclientcert=1pg_hba.confの適切なhostssl行に追加します。 そうすると、SSL接続の開始時にクライアントへ証明書が要求されます。 (クライアント上での証明書の設定方法については33.18を参照してください。) サーバは、クライアントの証明書が信頼する認証局のいずれかにより署名されていることを検証します。

既存のルート証明書に連鎖する中間証明書は、クライアントに保存することを避けたい場合にroot.crtに含めることができます(ルート証明書と中間証明書がv3_ca拡張で作成されている場合)。 ssl_crl_fileパラメータが設定されている場合、証明書失効リスト(CRL)項目も検査されます。 (SSL証明書の使用方法を示す図についてはhttp://h71000.www7.hp.com/doc/83final/ba554_90007/ch04s02.htmlを参照してください。)

認証オプションclientcertはすべての認証方式について利用可能ですが、pg_hba.confhostsslとして指定された行でのみ有効です。 clientcertが指定されていない、または0と設定されている場合でも、認証局のリストが設定されていれば、サーバはその認証局に対してクライアント証明書の検証を行いますが、クライアント証明書を提示することを要求しません。

クライアント証明書を設定している場合、接続の安全性を提供するとともに証明書でユーザ認証を制御できるようにcert認証方式を使用したいと考えるかもしれません。 詳細については20.3.9を参照してください。 (cert認証方式を使用している場合は、明示的にclientcert=1を指定する必要はありません。)

18.9.2. サーバにおけるSSL関連ファイルの利用

表 18.2にて、サーバにおけるSSLの設定に関連するファイルをまとめます。 (表示されているファイル名はデフォルトまたは一般的な名前です。異なる名前を個別に設定することもできます。)

表18.2 SSLサーバファイルの使用方法

ファイル内容影響
ssl_cert_file ($PGDATA/server.crt)サーバ証明書サーバの身元を示すためにクライアントに送信します
ssl_key_file ($PGDATA/server.key)サーバの秘密鍵サーバ証明書が所有者によって送られたことを証明します。証明書所有者が信頼できることを意味しません。
ssl_ca_file ($PGDATA/root.crt)信頼できる認証局信頼する認証局により署名されたクライアント証明書か検査します。
ssl_crl_file ($PGDATA/root.crl)認証局により失効された証明書クライアント証明書はこの一覧にあってはいけません。

サーバは、サーバ起動時及びサーバ設定がリロードされるたびに、これらのファイルを読み取ります。 Windowsシステム上では新しいクライアント接続のために新しいバックエンドプロセスが生成されるたびに再読み込みされます。

サーバ起動時にこれらのファイルのエラーが検出された場合、サーバは起動を拒否します。 ただし、設定のリロード中にエラーが検出された場合、ファイルは無視され、古いSSL設定が引き続き使用されます。 Windowsシステム上ではバックエンドの開始時にこれらのファイルのエラーが検出された場合、そのバックエンドはSSL接続を確立出来ません。 これらのすべてのケースでは、エラー状態がサーバログに記録されます。

18.9.3. 証明書の作成

365日有効なサーバ用の自己署名証明書を簡単に作るためには下記のOpenSSLコマンドを実行してください(dbhost.yourdomain.comをサーバのホスト名に置き換えてください)。

openssl req -new -x509 -days 365 -nodes -text -out server.crt \
  -keyout server.key -subj "/CN=dbhost.yourdomain.com"

続けて以下も実行します。

chmod og-rwx server.key

サーバの秘密鍵および証明書を作成するための詳しい方法についてはOpenSSLの文書を参照してください。

テストには自己署名証明書を使用できますが、運用時は認証局(CA)(通常は事業全体のCA)により署名された証明書を使用する必要があります。

クライアントが身元を検証できるサーバ証明書を作成するには、まず最初に証明書署名要求(CSR) と公開/秘密鍵を作成します。

openssl req -new -nodes -text -out root.csr \
  -keyout root.key -subj "/CN=root.yourdomain.com"
chmod og-rwx root.key

その後、鍵を使用して署名要求に署名しルート証明書を作成します(Linux上のデフォルトのOpenSSL設定ファイルの場所を使用)。

openssl x509 -req -in root.csr -text -days 3650 \
  -extfile /etc/ssl/openssl.cnf -extensions v3_ca \
  -signkey root.key -out root.crt

最後に、新しいルート証明書によって署名されるサーバ証明書を作成します。

openssl req -new -nodes -text -out server.csr \
  -keyout server.key -subj "/CN=dbhost.yourdomain.com"
chmod og-rwx server.key

openssl x509 -req -in server.csr -text -days 365 \
  -CA root.crt -CAkey root.key -CAcreateserial \
  -out server.crt

server.crtserver.keyをサーバに格納し、root.crtをクライアントに格納します。 クライアントはサーバのリーフ証明書が信頼されたルート証明書によって署名されたことを確認できます。 root.keyは将来の証明書の作成に使用するために、オフラインで保存する必要があります。

中間証明書が含まれる信頼の連鎖を作成することも可能です。

# root
openssl req -new -nodes -text -out root.csr \
  -keyout root.key -subj "/CN=root.yourdomain.com"
chmod og-rwx root.key
openssl x509 -req -in root.csr -text -days 3650 \
  -extfile /etc/ssl/openssl.cnf -extensions v3_ca \
  -signkey root.key -out root.crt

# intermediate
openssl req -new -nodes -text -out intermediate.csr \
  -keyout intermediate.key -subj "/CN=intermediate.yourdomain.com"
chmod og-rwx intermediate.key
openssl x509 -req -in intermediate.csr -text -days 1825 \
  -extfile /etc/ssl/openssl.cnf -extensions v3_ca \
  -CA root.crt -CAkey root.key -CAcreateserial \
  -out intermediate.crt

# leaf
openssl req -new -nodes -text -out server.csr \
  -keyout server.key -subj "/CN=dbhost.yourdomain.com"
chmod og-rwx server.key
openssl x509 -req -in server.csr -text -days 365 \
  -CA intermediate.crt -CAkey intermediate.key -CAcreateserial \
  -out server.crt

server.crtintermediate.crtは証明書ファイルに束ねて連結し、サーバに格納する必要があります。 server.keyもまたサーバーに格納される必要があります。 サーバのリーフ証明書が信頼されたルート証明書にリンクされた一連の証明書によって署名されていることをクライアントが確認できるように、root.crtをクライアントに格納する必要があります。 root.keyintermediate.keyは将来の証明書を作成に使用するためにオフラインで格納する必要があります。