ファイルサーバに格納されたデータのセキュリティが、昨今大変重要 になっています。データが不正に改変された場合、企業は数千ドルを失う 可能性もあります。この前のセクションにおいて、 我々は認証機構を提供するために、Apache をビルドする際に LDAP 認証モジュールを組みこみました。しかし、HTTP トラフィックは非常に 安全性が低く、データはすべて平文で転送されます - つまり、LDAP 認証を行うユーザ ID やパスワードも同様に平文で転送されてしまうのです。 これが問題を引き起こします。誰もがユーザ ID/パスワードを覗き見て、 DAV 格納所へのアクセス権を取得できます。これを防ぐには、 基本的には HTTP + SSL もしくは HTTPS により HTTP トラフィックを 暗号化しなくてはなりません。HTTPS 上で転送されるものはすべて暗号化 されますので、LDAP のユーザ ID/パスワードは簡単には復号化できません。 HTTPS は443番ポート上で動作します。この前のセクションにおいて コンパイルをした結果、Apache はポート80番(通常の HTTP)と443番 (HTTPS)の両方をリッスンするようになっています。 もしあなたがこのサーバを DAV のためだけに使うつもりならば、 その場合ポート80番を閉じることを強くお勧めします。このセクションでは、 SSL に関する情報と、Apache HTTP サーバ上で SSL を管理するための情報を提供します。
SSL (Secure Socket Layer)は、ネットワーク層とアプリケーション層の間に 位置するプロトコル層です。名前が示す通り、SSL はあらゆる種類の トラフィック--LDAP, POP, IMAP そして最も重要なのが HTTP-- を暗号化するメカニズムを提供します。
以下に SSL に含まれる層を非常に簡易化した構造を示します。
+-------------------------------------------+ | LDAP | HTTP | POP | IMAP | +-------------------------------------------+ | SSL | +-------------------------------------------+ | Network Layer | +-------------------------------------------+ |
SSL で利用される暗号化技術には、公開・秘密鍵、共通鍵、 そしてメッセージダイジェストの三種類があります。
公開・秘密鍵暗号方式 - SSL コネクションの開始: このアルゴリズムの場合、暗号化と復号化は一組の公開鍵と秘密鍵を利用して 実行されます。ウェブサーバは秘密鍵を保持し、公開鍵を認証書の中に入れて クライアントに送ります。
クライアントが、HTTPS を使いウェブサーバにコンテンツを要求する。
ウェブサーバは、サーバの公開鍵を含むデジタル証明書を付けて応答する。
クライアントは、証明書の期限が切れていないか調べる。
それからクライアントは、証明書を署名した認証局が、ブラウザの信頼できる 認証局のリストの中にあるか調べる。これが、我々が信頼できる CA から証明書 を得る必要がある理由です。
その後でクライアントは、ウェブサーバの Fully Qualified Domain Name (FQDN) が、証明書にある Common Name (CN) と一致するか調べる。
すべて条件を満たせば、SSL コネクションが開始される。
注記:: 秘密鍵で暗号化されたものは、公開鍵を使ってしか復号化できません。 同様に、公開鍵で暗号化されたものは、秘密鍵を使ってしか復号化できません。 公開鍵だけが暗号化に使われ、秘密鍵は復号化に使われるというありがちな 誤解があります。これは正しくありません。いずれの鍵も暗号化、 復号化に使えます。しかし、片方の鍵で暗号化されれば、 その場合はもう片方の鍵で復号化しないといけません。 例えば、公開鍵を用いて暗号化したメッセージを公開鍵で復号化 はできません。
秘密鍵を暗号化に使い、公開鍵を復号化に使うことで、 受信側に対し、送信側の完全性を保証します。公開鍵を暗号化に使い、 秘密鍵を復号化に使うことで、意図する受信側(秘密鍵の所有者) だけがデータにアクセスすることを保証します。 (つまり、秘密鍵を保持する人だけが、メッセージを復号化できます)
対称鍵暗号方式 - 実際に転送するデータの暗号化を行う : SSL コネクションの確立後、CPU に対する負荷が 公開・秘密鍵暗号方式より軽いので、データの暗号化には対称鍵暗号方式が 利用されます。対称鍵暗号方式では、データの暗号化 も復号化も同一の鍵で行われます。対称鍵暗号方式で利用される鍵は、 SSL セッションを始動する過程で、公開・秘密鍵暗号方式を用いて交換されます。
メッセージ・ダイジェスト サーバは、 転送されたデータの完全性を検証するのに HMAC, SHA, MD5 などのメッセージ・ダイジェストアルゴリズムを利用します。
Apache をコンパイルする間に、我々はテスト用証明書を作成しました。 我々はこの独自の証明書を作成するのに、mod_ssl により提供される makefile を使用しました。我々は以下のコマンドを用いました。
# make certificate TYPE=custom |
テスト目的にはこの証明書が利用できます。
実運用を行うには、認証局 (Certificate Authorities。以下、CA) から証明書を取得する必要があります。認証局は認証ベンダであり、 ユーザのブラウザクライアントに信頼できる CA としてリストアップされています。暗号アルゴリズムについて解説したセクション で述べたように、もし CA が信頼できる認証局のリストに入っていないと、 ユーザは保護されているサイトに接続しようとした際に警告メッセージを もらうことになります。
同様に、テスト用の認証書では、ユーザのブラウザに警告メッセージ が表示されることになります。
CSR、証明書署名要求は、信頼できる CA に送り署名してもらう 必要があります。このセクションは、CSR を作成し、それを自分で選んだ CA に送る方法について説明します。以下に示すように、 # openssl req コマンドが CSR の作成に利用できます。
# cd /usr/local/apache/conf/ # /usr/local/ssl/bin/openssl req -new -nodes -keyout private.key -out public.csr Generating a 1024 bit RSA private key ............++++++ ....++++++ writing new private key to 'private.key' ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:US State or Province Name (full name) [Some-State]:California Locality Name (eg, city) []:San Jose Organization Name (eg, company) [Internet Widgits Pty Ltd]:Seagate Organizational Unit Name (eg, section) []:Global Client Server Common Name (eg, YOUR name) []:xml.seagate.com Email Address []:saqib@seagate.com Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []:badpassword An optional company name []: |
"PRNG not seeded": あなたのシステムに /dev/random がないと、 "PRNG not seeded" エラーメッセージが出ます。 その場合、以下のコマンドを利用できます。
some_file.ext をご利用のファイルシステムに どんなファイルでも指定可能です。 OpenSSL が、種を生成するのにそのファイルを使用するのです。
この時点で、証明書署名要求を生成するために、 サーバの位置について何度か尋ねられます。
注記:あなたの Common Name は、dav.server.com といったウェブサーバの完全修飾 DNS(FQDN)名になります。あなたが何か他のものを入力してしまうと、 正しく動作しません。将来必要になりますので、ここで使用するパスワードは 忘れないでください。
このプロセスが完了すると、あなたは private.key と public.csr を取得します。 認証局に public.csr を提出する必要があります。 この段階では、public.key はまだ暗号化されていません。 暗号化するには以下のコマンドを実行してください。
# mv private.key private.key.unecrpyted # /usr/local/ssl/bin/openssl rsa -in private.key.unecrpyted -des3 -out private.key |
認証局はあなたのリクエストを処理すると、エンコードされた証明書 (デジタル証明書)をあなたに送り返します。 デジタル証明書は、X.509バージョン3により定義されるフォーマットになります。以下に、典型的なX.509バージョン3デジタル証明書の構造を示します。
証明書
バージョン
シリアル番号
アルゴリズム ID
発行者
有効期間
証明書の発行日時
証明書の有効期限
Subject
被証明者の公開鍵情報
公開鍵アルゴリズム
RSA 公開鍵
拡張領域
証明書署名アルゴリズム
証明書署名
X.509証明書を検証するには、以下のコマンドを使用します。
# openssl verify server.crt server.crt: OK |
server.crt は、デジタル証明書を含むファイル名です。
デジタル証明書の中身は、以下のように # openssl x509 コマンドを使用することで見ることができます。
# openssl x509 -text -in server.crt
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 312312312 (0x0)
Signature Algorithm: md5WithRSAEncryption
Issuer: C=US, O=GTE Corporation, CN=GTE CyberTrust Root
Validity
Not Before: Feb 8 03:25:50 2000 GMT
Not After : Feb 8 03:25:50 2001 GMT
Subject: C=US, ST=New York, L=Pelham, O=xml-dev, OU=web, CN=www.xml-dev.com/Email=saqib@xml-dev.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
............
............
Exponent: 65537 (0x10001)
Signature Algorithm: md5WithRSAEncryption
............
............
|
あなたはこの証明書をサーバ上に置き、 Apache にその位置を指定する必要があります。
本例では、秘密鍵は /usr/local/apache2/conf/ssl.key/ ディレクトリに置かれ、そしてサーバ証明書は /usr/local/apache2/conf/ssl.crt/ ディレクトリに置かれます。
認証局から受信したファイルを /usr/local/apache2/conf/ssl.crt/ ディレクトリに server.crt という名前でコピーしてください。
--> そして、先ほどの手順で生成された private.key を /usr/local/apache2/conf/ssl.key/ ディレクトリに置いてください。
その後で、正しい秘密鍵とサーバ証明書ファイルを指すよう /usr/local/apache2/conf/ssl.conf を修正します。
# Server Certificate: # Point SSLCertificateFile at a PEM encoded certificate. If # the certificate is encrypted, then you will be prompted for a # pass phrase. Note that a kill -HUP will prompt again. Keep # in mind that if you have both an RSA and a DSA certificate you # can configure both in parallel (to also allow the use of DSA # ciphers, etc.) SSLCertificateFile /usr/local/apache2/conf/ssl.crt/server.crt #SSLCertificateFile /usr/local/apache2/conf/ssl.crt/server-dsa.crt # Server Private Key: # If the key is not combined with the certificate, use this # directive to point at the key file. Keep in mind that if # you've both a RSA and a DSA private key you can configure # both in parallel (to also allow the use of DSA ciphers, etc.) SSLCertificateKeyFile /usr/local/apache2/conf/ssl.key/private.key #SSLCertificateKeyFile /usr/local/apache2/conf/ssl.key/server-dsa.key |
ウェブサーバに格納される RSA 秘密鍵は、通常暗号化されており、 そのファイルを解読するにはパスフレーズを必要とします。そのため、 mod_ssl 付きで Apache を起動する際にパスフレーズを要求されるのです。
# apachectl startssl Apache/1.3.23 mod_ssl/2.8.6 (Pass Phrase Dialog) Some of your private key files are encrypted for security reasons. In order to read them you have to provide us with the pass phrases. Server your.server.dom:443 (RSA) Enter pass phrase: |
RSA 秘密鍵を暗号化するのはとても重要なことです。もし誰かがあなたの 「暗号化されていない RSA 秘密鍵」を手に入れれば、彼/彼女は容易にあなたの ウェブサーバを偽装できます。秘密鍵が暗号化されていれば、 ハッカーはパスフレーズをブルートフォース攻撃で破りでもしない限り 何もできません。強力な (つまり長い) パスフレーズを使用されることを お勧めします。
しかし、ウェブサーバを起動する度にパスフレーズを要求されるわけですから、 鍵を暗号化するのが悩ましい場合もあります。特にブート時の ウェブサーバの起動に rc スクリプトを利用していると、 パスフレーズを要求されて入力待ちとなり、 ブートプロセスが止まってしまいます。
秘密鍵の(パスフレースによる)暗号化をやめれば、パスフレーズの要求は 簡単に止められます。ただし、誰もこの鍵を手に入れられないようにしてください。 私としては、ウェブサーバ上で秘密鍵を復号化する前に、セキュリティの ガイドラインを厳しくし、安全化することをお勧めします。
鍵を復号化するには、
まず暗号化された鍵の複製を作成します。
# cp server.key server.key.cryp |
その後で暗号化されている鍵を書き換えてください。元の暗号化された鍵の パスフレーズを要求されます。
# /usr/local/ssl/bin/openssl rsa -in server.key.cryp -out server.key read RSA key Enter PEM pass phrase: writing RSA key |
復号化された秘密鍵を安全化する一つの手法として、それを root からしか見えなくするというのがあります。
# chmod 400 server.key |