PKIの適用事例を検証する：PKI基礎講座（6）
連載のこれまでの回では、主にPKIを支える要素技術や考え方、あるいは法整備といったところに焦点を当てて解説してきた。読者の中には、「もう理屈はいいから、PKIってどうやって使われるのかを教えてよ」という方もいるのではないだろうか。そんな声におこたえして……というわけでもないのだが、今回はPKIが実際にどのように使われているのか、適用事例を幾つかご紹介したいと思う。
A社の場合〜SSLクライアント認証
A社の場合、すでに同社の代理店がWebを使用して予約や発注処理を行うシステムを導入していた。ただし、ユーザーの認証はIDとパスワードレベルで行っており、ここにセキュリティ上の脅威を感じ、PKIの導入に踏み切ることにした。
このケースでは、ユーザー認証のセキュリティレベルを高めることが目的なので、比較的導入しやすいSSLクライアント認証を適用させることにした。ここでA社の場合にポイントとなったのが、既存のシステムになるべく変更を加えることなく、認証部分のみをPKIベースに移行することだった。A社の既存システムの構成は図1のようなものである。Netscape Application Server（NAS）配下で稼働するアプリケーションは、Webブラウザ側からPOSTされたユーザーIDおよびパスワードを受け取り、それをあらかじめ登録されたユーザーDBと突き合わせることにより認証を行っていた。
図1 A社の既存システム。ユーザーの認証作業は、Netscape Application Server配下の各アプリケーションがユーザーDBを参照して行っていたPKIへの対応方法
PKIを導入するにあたって、まずはこのユーザーDBと連携した証明書発行の仕組みが必要となった。まず、Netscape Enterprise Server（NES）での認証機能を生かすため、LDAPのディレクトリサーバを導入し、このLDAPサーバがユーザーDBと完全に同期をとるような形をとることにした。具体的には、ユーザーDBの登録プログラムに若干手を入れて、ユーザーDBの登録と同時にLDAPにもユーザー情報を登録するようにしたのである。ユーザーDBとLDAPのディレクトリサーバ上に登録が完了したら、ユーザーに登録完了の通知が郵送される。ここには、証明書の申請用WebページのURLと申請時に必要となるPINコードが記入してあり、ユーザーはあらためてそのURLにアクセスしてPINコードを入力することで、証明書の発行申請を行う。
仮に、証明書発行申請用のURLが第三者に知られてしまったとしても、このPINコードがない限り証明書の発行申請が行えないような仕組みを実装し、発行段階でのなりすましのリスクを排除するようにしたのである。
証明書が発行されたら、その証明書をLDAPの該当ユーザーのエントリに追加する。ユーザーは発行された証明書をWebからダウンロードする。これで、ユーザーが業務システムを使用する準備が整ったことになる。
ユーザー認証とアプリケーション連携
さて、次は実際にユーザーがログインしてきたときの処理だ。ユーザーが証明書を提示し、WebブラウザとWebサーバの間でSSLのセッションを張る際、NESがディレクトリサーバをサーチし、その証明書に適合したエントリが存在するかどうかをチェックする。さらに、ユーザーから提示された証明書が、該当するディレクトリのエントリに存在するものと一致するかどうかもチェックする。これが一致すれば認証は完了で、ユーザーはアプリケーションにログインし、業務処理を行うことができるのである。
だが問題なのは、いまログインしているユーザーが一体だれなのか、アプリケーション側でハンドリングできなければならない点だ。前述のように、既存システムではアプリケーションが入力されたユーザーIDとパスワードをハンドリングして直接認証を行っていたのであるが、認証部分がアプリケーションから切り離されたため、認証部分とアプリケーションの橋渡しをしてやる仕組みが必要になるのである。もしLDAP上にユーザーIDを格納しておくことが可能であれば、NESの仕組みでそれを環境変数にセットすることができる。ただ、このケースではさまざまな理由からLDAP上にはユーザーIDを書き込むことができなかった。
そこで、NESのプラグインという形でモジュールの作り込みを行った。このモジュールは証明書の内容をもとにしてユーザーDBからIDを取得する。取得したIDは環境変数にセットされ、そのままNASとその配下にあるアプリケーションに引き渡されるという仕組みだ。これによりアプリケーション側は、従来までPOSTされたデータからIDを取得しユーザーDBに対して独自の認証を行っていた部分を、単に環境変数からIDを取得するように改変するだけで対応が可能になったのだ（図2）。
図2 PKI導入後のA社のシステム。認証作業はNetscape Enterprise Server（Webサーバ）とLDAPサーバとの間で行われるようになった。既存アプリケーションでユーザー情報の取得が必要な場合に対応するため、Webサーバに認証用のプラグインを用意し、アプリケーション側では環境変数を参照するだけでユーザーIDが取得できるようにしたこのシステムのポイント
このシステムでは、
- アプリケーションの改変を少なくし、短期間でのサービスインを実現する
- 既存のシステムと連携した形で証明書の発行を行う
という2点がポイントとなった。実際、システムの構想から約2カ月という短期間でサービスを立ち上げることができた。
B社の場合
〜OCSPレスポンダで高付加価値検証サービス
B社の場合、マーケットプレイスを構築し、電子商取引を行いたい企業に対してそれを提供するというビジネスモデルを実現しようとした。実際に電子商取引を行うユーザーがマーケットにログインする際の認証を、PKIベースのものにしようというのである。
ここで、単に認証をPKIベースで行うだけではなく、さらに付加価値の高いサービスを実現したことが、このシステムの大きな特徴となっている。このシステムの構成図は図3のとおりだ。
図3 B社の構築したマーケットプレイスのシステム。OCSPレスポンダを用いて、証明書によるユーザーの認証のみならず、そのユーザーが実際に取り引きを行ってもよいか検証できるという、さらに業務内容に一歩踏み込んだ機能を実現しているOCSPに付加価値を付ける
このシステムでは「OCSP」というプロトコルを、単に証明書の有効性の判断のみに使用するのではなく、ユーザーが取引自体を行ってよいかどうかという、もう一歩業務に突っ込んだ形の判断を行っている。
これを実現するために、まずOCSPレスポンダに業務システムと連携したロジックを組み込まなければならない。具体的には、OCSPレスポンダのプラグインモジュールとして、取引管理DBとの連携を行う仕組みを実装した。取引管理DBは、文字どおりユーザーの取引状態を管理しているデータベースである。ここには、これまでのユーザーの取引実績や取引額などがデータとして蓄積されている。もしこれまでの取引実績や現在の取引額からみて、もうこれ以上取引を行わせてはならないユーザーが存在した場合、その取引可否はこのデータベースを参照して判断することになるのである。
では、OCSPレスポンダにこのデータベースを参照させることによって、どのようなことが実現できるのだろうか。まず、取引がバイヤーとサプライヤーの間で行われることとし、バイヤーがサプライヤーに対して発注処理を行うケースを考えてみよう。まずバイヤーが発注のアクションを起こしたときに、マーケットにあるサーバがOCSPレスポンダに対して問い合わせを送信する。OCSPレスポンダは、以下の検証作業を行う。
(1) バイヤーの証明書は有効か
(2) サプライヤーの証明書は有効か
(3) バイヤーはその取引を行うことができるか
(4) サプライヤーはその注文を受けることができるか
このシステムの場合、取引可否は現在取引しようとしている金額に依存するものなので、上記(3)(4)についてはトランザクションベースで検証していくしかない。通常であれば、OCSPレスポンダに証明書の有効性の問い合わせを行い、さらに別の仕組みを使って業務的な取引可否の判断を行うことになるだろう。OCSPレスポンダに取引管理DBを参照するロジックを付加することによって、上記の(1)から(4)までの検証作業について、アプリケーション側はOCSPレスポンダへの問い合わせを行うだけで可能になった。
このケースのように、PKI関連のプロダクトに業務ロジックを実装することには賛否両論があると思う。業務系は業務系、PKIはPKIとして切り離されていた方が、後のメンテナンスなどを考えると効率的だという考え方にも一理あると思う。ただ何度もいうように、PKIは「インフラ」であり、それ自体が独立して存在するということはまれだろう。ほとんどの場合が業務システムで使用されることを前提としており、それを考えると、このようなアプローチは今後のPKIのあり方を占ううえでも非常に興味深いものだと思う。
今回のまとめ
今回は、PKIの適用モデルとして2つの例をご紹介した。いずれの場合にも共通していえることは、PKIを使用する業務や適用範囲を見据え、いかにそれに適合するような仕組みを構築していくかが非常に大きなポイントになるということだ。いろいろなところで話をするのだが、適用業務のないPKIは存在しない。あくまでもPKIは「インフラ」であり、それをどのような方法で使用するのか、PKIによって守るべきものは何なのか、それを使用する人たちはどのような人たちなのかをきちんと押さえておかないと、非常に使い勝手の悪い、あるいは非常に運用しにくいシステムが出来上がってしまう。
何かPKIというと、新しい分野ということで、これまでのシステムとはかけ離れた特別な扱いを受けることが多いように思う。ただ、これまで見てきたように基本的な考え方はいままでのシステム構築と何ら変わることはなく、使う人たちが使いやすく、運用する人たちが運用しやすく、そしてシステムの目的がきちんと達成されるという、至極当たり前のことが重要なのである。
Copyright © ITmedia, Inc. All Rights Reserved.
ITmediaはアイティメディア株式会社の登録商標です。