PKIの適用事例（2）：PKI基礎講座（7）

～試験運用から全社展開へ～

» 2001年05月11日 00時00分公開

[浅野昌和，日本ボルチモアテクノロジーズ]

　今回は、PKI導入のケーススタディとして、架空の会社を想定し、その会社が実際にPKIを導入していくまでのステップを見ていくことにしよう。

PKI導入〜試験運用から全社展開へ

　A社は社内のシステムが大規模になってきたことや、社内外において重要かつ機密性の高い情報がメールでやりとりされるケースが増えてきたことなどを考え、社員全員に証明書を格納したICカードを配布するという構想を打ち出した。

　社員数は関連会社を含めると1万3000人程度。ICカードそのもののコストや、その配布などの運用にかかるコストを考えると、かなりのものになる。しかし、PKI対応の社員証を配布することによってどの程度の効果が得られるのか、また、実際にそれを運用する際のリスクや正確なコストは一体どのくらいになるのか、未知数の部分が多かった。

　そこでA社は、機密情報を取り扱うことが多い設計部門に所属する社員100名程度に証明書を配布し、その部門でのみ試験的にPKIの導入を行うことにした。

●インハウスか？アウトソースか？

　さて、最初に検討が必要なのは、自社の環境の中に認証局を構築するか、あるいは外部の証明書発行サービスを利用するかということだ。当面の証明書の発行枚数は100枚程度と多くはないものの、将来的には1万数千枚の証明書を発行することになる。また、これを機会に認証局の運用についてのノウハウを蓄積し、将来的にほかのビジネスに応用していきたいという意向もあり、自社内で認証局を構築するという選択を行った。

　以前は、コスト面から考えると「大量発行はインハウス、少量発行はアウトソース」という考え方が大勢を占めていたが、認証局を構築する製品のライセンスポリシーや運用コストなどを考えると、両者の間にあまり差はなくなってきたといえるだろう。

●証明書の目的の明確化

　次に、今回発行する証明書の利用目的を再度明確化する。今回のPKI導入の大きな目的は、将来的な社員証向け証明書の試験導入ということだが、どのような利用方法をターゲットにするのかを以下の2つに絞った。

(1) S/MIMEメールの利用
(2) 業務システムへのログイン認証

　両者とも将来的に全社員に証明書を配布した場合にも、その大きな目的として挙げられるものである。

●S/MIMEメールの利用

　S/MIMEはMIMEの拡張仕様として作成されたもので、暗号化や電子署名の付加を施したメールの送受信を実現するためのものだ（図1）。意外と知られていないことだが、広く一般に出回っているメーラ（OutlookやOutlook Express、Netscape Messengerなど）には、このS/MIMEが実装されている（画面1）。

図1　S/MIME導入により、機密性確保と改ざん防止を実現する

画面1　一般によく使われているメーラには、S/MIMEが標準で実装されていることが多い。画面はOutlook ExpressでのS/MIMEの設定ダイアログ

　A社では、社内のメーラをOutlook Expressに統一しており、設計部門内のメールのやりとりについては、すべて暗号化と署名を施した状態で行うこととした。

●業務システムへのログイン認証

　もう1つの大きな柱が、業務システムのログイン時の認証にPKIを使用することだ（図2）。将来的に全社員に証明書が配布された場合には、シングルサインオンの仕組みを導入してユーザーとその権限を一元管理し、PKIを使用した認証と組み合わせた大規模な仕組みを導入する構想になっている。

図2　全社員に証明書を配布。業務システムへのログインの際の認証には、この証明書が必要となる

　今回の試験導入において、どのような形でそれを検証するかが大きな焦点になっていたが、取りあえず社内のスケジュール管理や設備予約などを行うイントラネットのシステムにおいてPKIベースの認証の仕組みを導入し、その使い勝手や運用面を検証していくことにした。

証明書の発行手順はどうするか？

　次に証明書のライフサイクルと運用のフローについての検討を行った。

　まず、スマートカードをどのような形で作成するかが問題になった。100枚程度の発行なので、印刷会社に依頼するとコストが高くなってしまい、かといって1枚1枚手動で作成していくのには数が多すぎる。結局A社は、ICチップへの書き込み機能のあるカードプリンタを導入し、これを使用して社員証を発行することにした。

　将来的に全社員に対して社員証を発行するということになれば、当然、人事データベースを元にして証明書の発行処理を行っていくことになる。今回のパイロットケースでは、なるべくそれに近い形を取るべきだろうということで、現在人事データベースに登録されている設計部門の人事データを元に、証明書を自動的に発行するようなシステムを作成した。当然、最終的に全社員が対象になった際にも、その仕組みをそのまま利用することが可能なよう考慮している。さらに、新入社員や中途入社の社員がこの部門に配属された際に使用できるように、個別の情報を人事データベースより抽出し、そのデータに対してのみ証明書を発行するような機能も付加した（図3）。

図3　検討の結果、このサンプルケースの会社では、自社でICカードへの証明書の組み込みを行うことになった。人事DBからデータを抽出し、それをもとに証明書を発行。カードプリンタを利用してカードへの書き込みを行う

　A社の認証局の運用主体は情報システム部となるのだが、このケースでは認証局側は特に加入者に対する審査を行わない。人事部が登録する人事データベースを信用して証明書の発行処理を行うことになる。ここで注意しなければならないのは、人事データベースが改ざんされてしまったり、あるいは人事部がデータベースに対して誤った登録をしてしまうことだ。これらはPKIの導入に関係なく大きな問題となる点であるが、A社ではこれを機会に人事部に対する教育の徹底と、人事データベースに対するセキュリティについて見直しを行うことにした。

　発行手順が決まったところで、証明書を配布する方法を検討することにする。まず、ICカードは部門長経由で本人に配布してもらうこととした（図4）。カードの初期PINコードはとりあえず社員コードと同じものを設定し、各自にスマートカードが渡った時点で必ずPINを変更してもらうように徹底した。この場合、万が一部門長が不正を行おうとしたり、あるいは部門長からの配布方法に問題があった場合には、なりすましなどの恐れがある。これは、そのリスクと、もし不正が発覚した場合には、部門長に大きな責任が課せられることを十分理解してもらうこととした。

図4　発行されたICカードは、部門長を経由して各社員に配られることになった。この場合、部門長が不正を行ったり、配布方法に問題があった場合に、なりすましなどが発生する恐れがあるが。部門長に対して、その責任を負ってもらうことを十分理解してもらうことにした

●証明書の有効期間と更新

　次に、証明書の有効期間を決めなければならない。社員証というものの性質とICカードという比較的コストの高いメディアを使用することを考え、最初の有効期限は3年後の3月末日とした。次回更新以降は有効期間3年1カ月、更新年の3月初めに発行することとし、前の世代の証明書と有効期間が1カ月重なるようにした。

　基本的に更新の処理は新規発行時と同様の手順とした。また、前の世代のカードは暗号化されたメールの復号の際に必要なため、回収は行わないこととした。

●証明書の廃棄（失効）と再発行

　社員がICカードをなくしてしまった場合には、カードに入っている証明書を廃棄（失効）することになる。

　通常、廃棄の手続きには新規発行時と同様のレベルでの厳密な本人確認が必要となる。署名付きのS/MIMEメールで廃棄の申請を行う方法もあるが、ICカードに証明書が格納されており、カードを紛失してしまった場合には署名付きメールを出す方法がない。今回は社員証代わりということもあり、本人の押印と上司の押印のある定型の書類を情報システム部に提出（緊急を要する場合はFAX）することにした。

　さらに、廃棄に伴う再発行が必要な場合には同様の申請書類を提出してもらい、再発行することとした。

運用開始後のトラブルにはどう対処する？

●カードを家に忘れてしまったら……

　さて、社員証用のICカードということで、そのカードを家に忘れてしまった場合にどうすればよいのか、という問題がつきまとう。どの会社にも、社員証を家に忘れてきてしまうという人は必ずいるもので（筆者もその1人だが……）、そのような人がその日の業務ができないのは自業自得……という考え方もできなくはない。しかし、ある社員の業務が仮に1日できなくなってしまうと、その社員1人だけでなく、周囲の人も困ることになる。

　今回のケースで社員証を忘れた場合（つまり一時的にその秘密鍵および証明書が使用できなくなった場合）、

(1) 過去に自分あてにきた暗号化メールの復号・解読ができない
(2) 業務システムへログインできない

といった不都合が発生することが考えられる。

　(1)については、1日程度であれば何とかなるかもしれないが、(2)については1日止まってしまったら問題が大きい。

　これに対応するために、A社では、有効期間の短い（1日から1週間程度）証明書を発行し、業務システムではその証明書をその期間のみ該当社員のものであるという設定を行なって、ログインを許すような形にした。当然、期間が短いので、ICカードに格納するタイプではなく、FDに格納して本人に渡すという方法をとることにした。

●秘密鍵は認証局側で保存しておくべきか？

　加入者の秘密鍵を認証局側で生成する場合、その鍵を認証局側に保持（アーカイブ）しておくかどうかは、非常に大きな問題である。

　認証局側に加入者の秘密鍵が存在しているということは、何か不正があって加入者が被害受けた場合、真っ先に認証局が疑われるというリスクを負うことになる。しかし、暗号用に鍵を用いていた場合、加入者がもし秘密鍵を紛失してしまうと、以前暗号化されたものが永久に復号できなくなってしまう。

図5　アーカイブされた秘密鍵が盗まれたら一大事だ

　一般的に、電子署名に厳密性を持たせるのであれば秘密鍵はアーカイブせず、暗号化に用いる場合などで利便性を優先させるときには秘密鍵をアーカイブする、ということがいえる。だが、それぞれの要件によってこのあたりの運用は変わってくるだろう。署名用と暗号化用で1つの鍵だけを使っていると、上記の問題でジレンマに陥ってしまうことが多い。これに対応する方法として、署名用と暗号化用で別の鍵を使用するデュアルキーという考え方も存在する。ただし、現状ではこのデュアルキーに対応するアプリケーションの数は非常に少ない。

　A社では、配布対象が社員に限られており、主な目的の1つがS/MIMEメールの利用ということを考慮して、認証局側で秘密鍵のアーカイブを行うこととした。ただし、アーカイブした秘密鍵を取り出す際には、オペレータの認証を厳密に行うように十分考慮している（図5）。

本格展開に向けて

　今回の試験運用を経たところで、将来的なPKIの全社導入に向けて、さらに幾つかのポイントを挙げてみることにしよう。

●マイルストーンを置いて試験運用の経過・結果を分析する

　せっかくの試験運用でも、検証すべきポイントがずれていたり、明確になっていなかったりすれば何も意味がない。今回は、大まかにシステムの使い勝手とPKI導入に伴う運用方法の検証という大枠の項目があったわけだが、「パイロットの期間中に社員証の紛失が何件ぐらい発生するか？」「使用者側のリテラシーはどこまで高められるか？」「認証局の運用に必要な人員はどのくらいなのか？」など具体的にポイントを挙げ、さらにマイルストーンを設定して、その都度の検証や必要に応じた運用方法の変更などを行っていく必要があるだろう。

●契約社員などの扱い

　社員以外にも、社員と同等のレベルで業務を行わなければならない契約社員や派遣社員を置いている会社は多いだろう。これらの社員は、一般的には正社員よりも在籍期間が短いため、証明書についても正社員より有効期間の短いものを発行するのが一般的だ。有効期間を決めるには、契約社員であればその契約期間を目安にするのが分かりやすいだろう。

●社員に対するトレーニング

　PKIというのは、その安全性が運用部分に非常に大きく依存している。認証局それ自体を運営する部門だけでなく、証明書を使用する側にも、利用方法と正しく使用されなかった場合のリスクを認識してもらう必要がある。

　試験運用の段階でリスクを見極め、運用を見直したりすることももちろん大切だが、社員に対してどのような形で何をトレーニングしていくべきなのかを考え、トレーニング計画を策定しておくことが重要だ。

　以上、架空のA社という会社の社員証を例にとって、PKI導入のシミュレーションをしてみたが、いかがだっただろうか。使用目的や用途によって、運用方法などのいわゆるポリシーの部分を柔軟に変えていく必要があることを理解していただけたのではないかと思う。また、A社のように社員証にPKIを絡めて導入していくという用途は、今後増えていくことが予想される。もしそのような形で導入を検討されている方がいれば、参考にしていただければと思う。

「次回」へ

「PKI基礎講座」バックナンバー