| PostgreSQL 9.1.5文書 | ||||
|---|---|---|---|---|
| 前のページ | 巻戻し | 第 17章サーバの準備と運用 | 早送り | 次のページ |
PostgreSQLは標準でSSL接続をサポートし、クライアント/サーバの通信がさらに安全になるよう暗号化します。 そのためにはOpenSSLがクライアントとサーバシステムの両方にインストールされ、構築時にPostgreSQLにおけるそのサポートが有効になっている必要があります（第15章を参照してください）。
SSLサポートを有効にしてコンパイルされた場合、PostgreSQLサーバは、postgresql.confにおいてsslパラメータをonにすることで、SSLサポートを有効にして起動することができます。 サーバは同じTCPポートで通常の接続とSSL接続の両方を待ち受け、クライアントとの接続にSSLを使用するかどうかを調停します。 デフォルトでは、これはクライアント側の選択肢です。 一部またはすべての接続でSSLの使用を必要とさせるためのサーバ側の設定方法に関しては項19.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ファイルがサーバのデータディレクトリに存在しなければなりません。 これらのファイルにはサーバ証明書と秘密キーがそれぞれ含まれます。 Unixシステムでは、server.keyの権限は所有者以外からのアクセスを許可してはなりません。 これはchmod 0600 server.keyというコマンドで実現できます。 秘密キーがパスフレーズで保護されている場合、サーバはパスフレーズの入力を促し、入力されるまでは起動しません。
サーバ証明書がクライアントで直接信頼している認証局ではなく、"中間"認証局により署名されている場合があります。 こうした証明書を使用するために、server.crtファイルに署名した認証局の証明書と、クライアントで直接信頼している"ルート"認証局までその親となる認証局の証明書を追加してください。 server.crtに複数の証明書が含まれる場合はすべて、ルート証明書を含めなければなりません。
クライアントに信頼できる証明書を要求するためには、信頼する認証局（CA）の証明書をデータディレクトリ内のroot.crtファイルに記述し、pg_hba.conf内の適切なhostssl行（複数もあり）にclientcertパラメータを1に設定します。 その後、SSL接続起動時にクライアントからの証明書が要求されます。 （クライアントにある証明書の設定方法については項31.17を参照してください。） サーバは、クライアントの証明書が信頼する認証局のいずれかにより署名されていることを検証します。 root.crlファイルが存在する場合、証明失効リスト（CRL）項目も検査されます。 （SSL証明書の使用方法を示す図についてはhttp://h71000.www7.hp.com/DOC/83final/BA554_90007/ch04s02.htmlを参照してください。）
pg_hba.confの中のclientcertオプションはすべての認証方式に対して有効ですが、hostsslとして指定された行のみに対してです。 clientcertが指定されていない、または、0と設定されている場合でも、root.crtファイルが存在すれば、サーバはroot.crtに対して存在するクライアント証明書の検証を行います。 しかしクライアント証明書の存在を要求しません。
root.crtは、クライアント証明書の署名に対して信頼できるとみなしている最上位のCAを列挙していることに注意してください。 原理的には、サーバの証明書を署名したCAを列挙する必要はありませんが、ほとんどの場合、そのCAはクライアント証明書でも信頼されています。
クライアント証明書を設定している場合、接続の安全性を提供するとともに証明書でユーザ認証を制御できるようにcert認証方式を使用したいと考えるかもしれません。 詳細については項19.3.10を参照してください。
表17-3にて、サーバにおけるSSLの設定に関連するファイルをまとめます。
表 17-3. SSLサーバファイルの使用方法
| ファイル | 内容 | 影響 |
|---|---|---|
| $PGDATA/server.crt | サーバ証明書 | サーバの身元を示すためにクライアントに送信します |
| $PGDATA/server.key | サーバの秘密キー | サーバ証明書が所有者によって送られたことを証明します。証明書所有者が信頼できることを意味しません。 |
| $PGDATA/root.crt | 信頼できる認証局 | 信頼する認証局により署名されたクライアント証明書か検査します。 |
| $PGDATA/root.crl | 認証局により失効された証明書 | クライアント証明書はこの一覧にあってはいけません。 |
server.key、server.crt、root.crt、root.crlファイルは、サーバ起動時にのみ検査されます。 ですので、これらのファイルの変更を有効にするためにはサーバを再起動する必要があります。
サーバ用の自己署名証明書を簡単に作るためには下記のOpenSSLコマンドを使ってください。
openssl req -new -text -out server.req
opensslから出される質問に答えてください。 この時、"Common Name"には確実にローカルホスト名を入力してください。 チャレンジパスワードは空白でも構いません。 このプログラムはパスフレーズで保護されたキーを生成しますが、4文字以下のパスフレーズは認められません。 パスフレーズを削除するためには（サーバの自動起動を行いたいのであれば）、下記のコマンドを実行してください。
openssl rsa -in privkey.pem -out server.key rm privkey.pem
既存のキーのロックを外すために、古いパスフレーズを入力します。 そして、下記を実行してください。
openssl req -x509 -in server.req -text -key server.key -out server.crt
このように、証明書を自己署名の証明書にして、キーと証明書とをサーバが検索する場所にコピーします。 サーバは、もしこのファイルがこれよりもゆるい権限の場合拒否するので、最後に以下を行います。
chmod og-rwx server.key
サーバの秘密キーおよび証明書を作成するための詳しい方法についてはOpenSSLの文書を参照してください。
自己署名証明書を試験のために使用することはできますが、クライアントがサーバの身元を検証できるように、運用時は（グローバルなCAの1つまたはローカルな認証局のいずれかの）認証局（CA）により署名された証明書を使用すべきです。 もしすべてのクライアントが組織においてローカルであれば、ローカルCAの使用が推奨されます。