ゼロから始めるインターネットセキュリティ講座


最終講義● お弁当屋さんサーバの運用　　　　　　　　　講師：宮川祥子


「株式会社アスキーのご厚意により、掲載しております」

第１回から前回までで、PKIの全体像とその構築方法について解説してきました。最終回となる今回は、第１回の冒頭で紹介したお弁当屋さんのWWWサーバで、サーバ／クライアント認証を実現するための具体的な手法について解説します

お弁当屋さんサーバモデル

　まず、第１回で説明したお弁当屋さんが実現したい機能をおさらいしましょう。

このために、これまで説明してきたPKIを使って、お弁当屋さんWWWサーバのサーバ認証と、顧客のクライアント認証を行なうというのが目的です。さらにここでは、よく注文してくれる顧客だけに特別の割引メニューを見せることにしましょう。この場合には、お得意様だけがアクセスできるページを用意する必要があります。

　まず、お弁当屋さんのホームページそのものが改ざんされていないということを保証したいので、WWWサーバのすべてのコンテンツをサーバ認証の対象とします。さらに、どの顧客が注文を行なったかも確実に把握したいので、お弁当を注文するページでクライアント認証を行ないます。また特別メニューのページは、お得意様だけがアクセスできるような設定にする必要があります。これは、提示されたクライアント証明書がお店の持っているお得意様リストに載っているときにはアクセスを許可し、それ以外はアクセスを拒否することで実現できます。これらの要求事項を図にまとめると、図１のようになります。次は、これらの機能を実現するための、認証局とWWWサーバの設定について解説していきます。


図1　お弁当屋さんモデル

認証局の設定

　商店街の認証局は、目的に応じていろいろな種類の証明書を発行しますが、発行する証明書の種類によって設定を変更する必要があります。もっとも注意する必要があるのは、X.509を拡張するためのX.509v3 Extensionの設定です。デフォルトのopenssl. cnfでは[usr_cert]というセクションで定義されている部分です。リスト１にサーバ用の証明書を発行する際の例を示します。 

リスト1●openssl.cnfの［usr_cert］セクション

[ usr_cert ]
# These extensions are added when 'ca' signs a request.

basicConstraints=CA:FALSE

nsCertType                     = server
# nsCertType = objsign
# nsCertType = client, email
# nsCertType = client, email, objsign

# This is typical in keyUsage for a client certificate.
# keyUsage = nonRepudiation, digitalSignature, keyEncipherment

# This will be displayed in Netscape's comment listbox.
nsComment                       = "OpenSSL Generated Certificate"
　basicConstraintsは、発行する証明書がCAの証明書かどうかを識別する設定です。WWWクライアントやサーバに対して証明書を発行する場合には、この値はFalseにしておく必要があります。この設定は、X. 509v3の標準ExtensionとしてRFC2459で定義されています。nsCertTypeは、クライアントとしてNetscapeを使う場合に必要なものです。nsCertTypeは以下のような値をとります。Netscapeは、各種証明書を読み込む際にこの値を見て、それぞれの証明書がどのような機能を持つのかを判断します。 

server：SSL Server
client：SSL Client
email：S/MIME
objsign：Object Sign
sslCA：SSL CA
emailCA：S/MIME CA
objCA：Object Sign CA
　今回使うのは、serverとclientです。証明書発行の際は、この値を間違えないことが必要です。なお、この設定は標準Extensionではなく、Netscape独自のものです。

　今回は詳しくは取り上げませんが、CAに対して証明書を発行する際には、このほかにもさまざまなExtensionを設定する必要があります。詳しくはRFC2459で解説されていますが、また機会があればこれらの設定についても取り上げたいと思っています。

サーバ認証のためのApacheSSLの設定

　次は、ApacheSSLの設定です。前回はテスト用の証明書を使った設定について解説しましたが、第２回で作ったサーバ用の証明書を使う場合も基本的な設定は同じです。ただし、テスト用の証明書には公開鍵と秘密鍵が両方含まれていましたが、第２回で作った証明書には公開鍵しか含まれていませんので、秘密鍵も別途指定した場所に置く必要があります。サーバ証明書は先月説明したhttpsd.conf内のSSLCertificate Fileで指定した場所に置きます。秘密鍵は、証明書を発行する際に作成した証明書リクエストの中に含まれています。このリクエストファイルを、httpsd.conf内のSSLCerti ficateKeyFileで指定した場所に置きます。

クライアント認証のためのApacheSSLの設定

　ここでは、前回説明しなかったApache SSLでのクライアント認証について説明します。クライアント認証を行なうことで

という２つを実現することができます。

　証明書を持ったクライアントにのみアクセスを許可する場合には、httpsd.confのSSL VerifyClientを設定します。SSLVerifyClientは０〜３の値をとり、それぞれ以下のような意味を持ちます。

０：認証を必要としない
１：クライアントは、証明書を提示して認証を受けることができる。ただし、この場合の証明書はサーバに信頼されているCA（SSLCACertificate Pathに証明書が格納されているCA）でなければならない。
２：クライアントは、サーバに信頼されているCAによる証明書を提出しなければならない ３：クライアントは、証明書を提示して認証を受けることができる。この場合の証明書は、サーバに信頼されているCAでなくてもかまわない。

　ここでは２を指定し、サーバに信頼されているCAから発行された証明書を持ったユーザーにのみ、アクセスを許可します。SSLCACertificatePathで指定したディレクトリに、サーバの信頼するCAの証明書を置きます。httpsd.confの設定を変更したら、 

% httpsdctl restart
を行なって、ApacheSSLを再起動しましょう。httpsdctlは、ApacheSSLのインストールディレクトリの下のbinにあります。

　次に「特定の」証明書を持ったユーザーにのみアクセスを許す場合の設定です。まずはhttpsd.confのSSLFakeBasicAuthを設定し、証明書によるアクセスコントロール機能を有効にします。ApacheSSLでのクライアント認証は、通常のApacheにおけるユーザー名とパスワードを使った認証の設定に、ちょっとした「細工」をすることで実現しています。通常のApacheで認証を行なう場合、httpd.confまたは認証を行なうディレクトリの.htaccessファイルで 

AuthType Basic
AuthName Secure-Directory
AuthUserFile /usr/local/apache/misc/Secure-
Users
require valid-user
と設定することで、AuthUserFileで指定されているファイル（ここでは/usr/local/apache/ misc/Secure-Users）に記述されているユーザー名とパスワードの組で認証を行なうことができるようになります。ApacheSSLでは、このAuthUserFileに細工をします。通常のAuthUserFileには、エントリとして

ユーザー名：暗号化されたパスワード

というデータが書かれています。このエントリは、Apacheのインストールディレクトリの下のbinディレクトリにあるhtpasswdコマンドを使うことで作成できます。Apa cheSSLで証明書を使ったクライアント認証をする場合は、上記エントリのかわりに、 証明書DN：passwordという文字列を暗号化した文字列 というエントリを登録します。証明書のDN（Distinguished Name）は、 

% openssl x509 -in 証明書ファイル名 -text
で得られる証明書データの“Subject：”エントリにあります。このエントリをユーザー名として使いますが、カンマ（,）をスラッシュ（/）に置き換えることと、エントリの頭にも/を加えることに注意してください。次にパスワード部分ですが、passwordという文字列を次のような方法で暗号化します。

　まず、htpasswd -cで新しいパスワードファイルを作り、tmpという仮のユーザー名（もちろんtmp以外でもいいです）を登録します。そして、そのtmpのパスワードとして“password”という文字列を指定します。できあがったファイルのtmpというユーザーのパスワードフィールドがpasswordという文字列を暗号化したものになりますので、これを先ほどのDNエントリのパスワードとして利用すればいいのです。これをコマンドで説明すると、次のようになります。 

% htpasswd -c passwd-file tmp
New password：pass____word_____ ←ユーザー入力部分
Re-type new password：pass____word_____ ←ユーザー入力部分
Adding password for user tmp
ここでできたpasswd-fileというファイルのtmpエントリのパスワード部分をコピーします。第２回で作成した宮川祥子の証明書DNを使ったエントリをリスト２に示します。 　実は、ApacheSSLのドキュメントを見ると「パスワードとして"xxj3IZMTZzkVA"という文字列を設定しなさい」と書いてあります。しかし、これは古いバージョンの設定方法が修正されずに残っているようで、現在ではこの文字列ではうまくいきません。上記で説明したように、htpasswdを使って暗号化を行なったものを使ってください。 
リスト2●クライアント認証のためのパスワードファイル

/C=JP/ST=kanagawa/L=fujisawa/O=Nikoniko Shopping Center/OU=customer/CN=Shoko Miyagawa/Email=miyagawa@nsc.org:9L9.sYFyIsvEE

サーバ／クライアント認証の動作確認

　では、設定したApacheSSLが正しく動作しているかを確かめてみましょう。ここでは、お弁当屋さんのWWWサーバ全体でサーバ認証を行ない、その中の注文のページでクライアント認証を行なうケースを想定します。クライアントには、あらかじめpkcs #12形式のクライアント証明書とCA証明書を組み込んでおきます。証明書の組み込みについては第２回を参照してください。

　まず、お弁当屋さんのホームページにアクセスします。通常のhttp://ではなくhttps://でURLを記述する点に注意してください。すると、画面１のようなダイアログボックスが現われます。これは、これから接続しようとしているホームページがサーバ認証されたものであることを示しています（このダイアログボックスは、CAの証明書をクライアントに組み込む際に「この証明書発行人をネットワークサイトの認証用に受けつける」という設定をしてある場合には表示されません）。サーバ証明書を受けつけてお弁当屋さんのホームページにアクセスできたら、次に注文ページに飛びましょう。


画面1　ホームページがサーバ認証されたものであることを証明するサーバ証明書

　お弁当の注文ページではクライアント認証を行なっているため、アクセスしようとすると画面２のようなダイアログボックスが表示されて、クライアント証明書の提出を求められます。そこで第２回で作成し、あらかじめクライアントに組み込んであるクライアント証明書を選択します。認証に成功すると、注文のページが表示されます。さらに、お得意様特別メニューのページにアクセスすると、もう１度クライアント証明書の提出を求められます。再度提出した証明書のDNと、前述の方法でサーバのアクセス許可リストに登録してある証明書DNが一致すれば、まちがいなくお得意様であると判断されて特別メニューのページにアクセスすることができます。もしクライアント認証で失敗する場合には、httpsd.confのアクセス制御の部分の記述と、パスワードファイルの記述を確認してみてください。


画面2　クライアント証明書の選択

注意：証明書によるアクセスコントロールは、クライアント証明書のDNだけを見て判断しています。しかし、実際にはお得意様と同じDNを持つ証明書は誰でも作ることができるので、この方法は厳密にはクライアント認証とはいえません。したがって、クライアント認証を設定していないWWWページでこの方法を使ってアクセスコントロールをした場合、不正なユーザーでもアクセスできてしまう可能性があります。証明書DNを用いたアクセスコントロールを行なう場合にはこの点に注意して、厳密な証明書の検証を必要とする場合には、かならずverifyClientを設定してクライアント証明書の検証を行なうようにしてください。

証明書リポジトリのへのアクセス

　最後に、LDAPによる証明書リポジトリにアクセスして、相手の公開鍵証明書やCAの公開鍵証明書を取得する方法を紹介します。今回の例では、お弁当屋さんもお客さんも同じCAが発行した証明書を使い、CAの公開鍵証明書はお客さんの秘密鍵に含まれていたので、証明書リポジトリの出番はありませんでした。しかし、たとえばお得意様に特別サービスのお知らせをS/MIME暗号メールで送りたいという場合は、証明書リポジトリにアクセスしてお得意様の公開鍵を入手する必要があります。

Netscapeによるアクセス
　証明書リポジトリであるLDAPサーバにアクセスするためには、まずLDAPサーバをNetscapeに登録する必要があります。Commu nicatorメニューの「アドレス帳」を選択すると、ウィンドウ右側にディレクトリのリス トが表示されます。ここに新しいLDAPサーバを登録します。ファイルメニューから「新しいディレクトリ」を選択し、LDAPサーバの名前と検索開始場所を指定します。検索開始場所とは、「ディレクトリのこの位置から下のエントリを検索する」という意味で、通常はLDAPサーバのルートDNを指定しておけばいいでしょう。LDAPサーバが登録できたら、サーバを選択して「検索」ボタンを押すと名前や電子メールアドレスなどの属性でLDAPサーバのエントリを検索することができます。
Outlook Expressによるアクセス
　ツールメニューの「アカウント」から、LDAPサーバが登録できます。編集メニューの「検索」から「人」を選ぶと、指定したLDAPサーバから電子メールアドレスなどの属性でエントリを検索できます。

PKIの現状と課題

　以上で４回にわたって解説してきたPKIを用いたセキュアな環境構築についての解説を終わりますが、最後にPKIの現状と私が考える今後の課題についてお話します。

　PKIを構築する上でもっとも大切なのは、CAをきちんと運用することです。すべての証明書はCAが信頼できるということを前提としているので、CAの運用がずさんではせっかくの証明書も信用できないものになってしまいます。では、CAの運用を「きちんと」するというのはどのようなことでしょうか。まずは、あたりまえのことですが「正しい証明書を発行する」ということです。ここでも少し述べましたが、証明書を発行する際には、BasicConstraintsなどのX.509v3 Extensionも正しく定義することが必要です。また、証明書の有効期間も重要です。たとえば１年ごとの契約で仕事をしている人の場合には、証明書の有効期限も１年間にしておくべきでしょう。

　CA自身がきちんとしたポリシーで運用されていることも大切です。商用の認証局にはCPS（Certification Practice Statement：認証局運用規定）とよばれる規則があり、サービスの内容や証明書が保証する範囲が定められています。このCPSのURLは、X.509v3 Extensionの証明書ポリシーとして記述することができます。CPSは、特に一般消費者など不特定多数の証明書ユーザーを想定する場合にはユーザーと認証局間の契約を示すものとなりますので、きちんと整備しておくことが望まれます。CPSを作成する際には、CAが発行する証明書がどのようなアプリケーションで利用されるのかを想定しておくのが大切なのはいうまでもないことです。

　CAはポリシーだけでなく、セキュリティ的にもきちんと守られていることが重要です。本格的な運用を行なうCAが守るべきセキュリティ基準については、国際セキュリティ標準としてISO15408が定められているので、それにのっとる必要があるでしょう。ISO15408ではデータの管理方法やウィルス対策にとどまらず、物理的な建物の管理や業務における権限の分散など、人的な部分まで規定されています。

　PKIをめぐる環境は日々変化しています。前回でも触れた電子署名法は、今国会で可決成立しました。この法案を含めたGPKI（政府認証基盤）構想も、ミレニアムプロジェクトの一部として始まっています。米国でも、当然のことながらFPKI（連邦PKI）計画が進行しています。民間の認証サービスは買収と業務提携が相次ぎ、数カ月の間に業界再編といった趣です。技術に関しても、連載中に新しいX.509v4のドラフトが公開されました。IETFでは、RFC2459の改訂が進んでおり、一方でQualified Certificate（法的効力をもつ証明書）やAttribute Certificate（属性証明書）の検討も進んでいます。今回は取り上げませんでしたが、CRL（証明書破棄リスト）をどのように管理／流通させるかという問題については、CRLを配布せずに証明書の有効性を確認するプロトコルであるOCSP（Online Certificate Status Protocol）についても、RFCの改訂が進んでいます。このようにPKIがどんどん拡張していく一方で、基本的な技術についてはほぼ固まったといってもいいでしょう。PKIを使ったアプリケーションは（もちろん省庁への各種申請も含めて）今後増加していくことが予想されます。WWW認証や電子メールの暗号化にとどまらず今後PKIがどのようなアプリケーション分野へと広がっていくのか、非常に興味深いところです。

謝辞　この連載を執筆するにあたって、多くの誤りの指摘や、有益な示唆をいただいた電子認証局市民ネットワーク福岡（CACAnet Fukuoka）のみなさんに感謝します。

この記事は、Ascii Network Pro 2000年8月号に掲載された記事を、株式会社アスキーのご好意によって掲載許可をいただいたものに、若干の加筆訂正を行ったものです。この場を借りて、株式会社アスキーに御礼申し上げます。