今回はPKI適用事例の3回目として、「電子調達」に関するPKIの適用事例を見ていこう。電子調達は、電子商取引の中でもビジネスモデルが非常に明確で取り組みやすい分野だろう。この電子調達にPKIを適用する際に、どのような点に注意すべきなのかを検証していく。
電子調達とは何か？
電子調達とは、文字どおり企業の調達行為を電子化したものだ。特に大企業になれば、調達業務にかかるコストはばかにできない。資材部門や調達部門といった部門が多くの要員を抱え、紙の書類を処理するのに四苦八苦しているというのはよく聞く話である。
また、このような状況の打開策は早くから検討されており、インターネットが普及する以前から、フレームリレー網などを使用したEDI（Electronic Data Interchange：電子データ交換）という形で早くから電子化されてきた分野でもある。インターネットが普及したことによって、この既存のEDIをインターネット化する動きや、新たに電子調達システムを導入しようという動きが盛んになっている。
●ケーススタディ〜C社の場合
ここで、また例によって架空のC社という会社を使ってケーススタディを行っていこう。大手メーカーであるC社は、現在紙ベースで行っている調達行為を電子化するという計画を立てた。調達元の取引先は約500社。C社が製造している製品の部品などが主な調達資材となっている。調達にかかる要員を含めたコストは莫大で、電子調達の導入という話が持ち上がったのである（図1）。
ただ、やはりインターネットを使うのであれば、セキュリティ、特に認証の部分についての不安が大きいということで、認証方式としてPKIを使用したSSLクライアント認証を採用することにした。
業務フローの見直し／証明書の内容の検討
●証明書の発行形態
C社はまず、PKIを導入するにあたって証明書の発行形態を検討した。ここで、証明書の発行形態についてもう一度整理してみよう。
(1) 証明書発行サービスを利用する
(2) 自社の認証局を構築し、発行局業務をアウトソーシング
(3) 自社の認証局を構築し、自社ですべて運用
C社の場合、証明書の発行枚数が「取引先約500社×担当者」ということで、最大2000枚程度を見込んでいた。有効期間1年の証明書を発行し、毎年更新することを考えると、コスト的に証明書発行サービスの利用は難しいということになった。結局、認証局運用に関するノウハウがないことを考え、自社に認証局を構築するが、発行業務はアウトソーシングする形を選択し、登録局（RA）は情報システム部が管理運用することになった。ただ、取引当たりの金額がさほど大きいものでなく、またある程度セキュリティレベルを確保したデータセンターがれば、自社内で運用するという選択肢も取ることができただろう。
●証明書の発行対象
ここで証明書の発行対象をもう一度整理してみよう。証明書の発行対象は調達業務における取引先であり、厳密にいえば取引先の担当者ということになる。C社の場合（多くの場合そうだと思うが）、これらの取引先との間には資材調達に関する契約関係が存在する。さらに、社内業務に使用するために、取引先はすべてデータベースに登録されている。これらの契約締結から取引先管理データベースへの登録までのワークフローは、社内で確立されている。この流れに証明書発行のフローを乗せることになったのだが、それについては後ほど詳細を見ていくことにしよう。
また、ここでポイントとして明確にしておきたいのが、「C社にとって『認証』すべきなのは一体どのような情報なのか」ということだ。C社にとっては、取引先の担当者個人の氏名がどうなっているかなどということは、はっきりいって重要でない。正規の取引先の正規の担当者であることが分かればよいのだ。
上記を踏まえて、実際の証明書の内容や発行フローをどのようにすべきなのか、見ていくことにしよう。
●証明書の内容
C社の取引先管理データベースには、取引先の「会社コード」と「支店コード」が採番され、そのコードによってすべて管理されている。証明書に格納する情報も、この取引先管理データベースの管理方法を踏襲する形にした。具体的にはSubject（発行先）のO（組織情報）に取引先の会社コードを、OUに支店コードを格納し、CNにはその会社／支店内の担当者の連番を振ることにした。SSLクライアント認証を使用して調達のアプリケーションにログインした後、アプリケーションが証明書中のこれらの情報を取得し、取引先管理データベースと連携して処理を行うことができる。
一般論として、このように証明書の適用アプリケーションが限られている場合には、アプリケーションの開発サイドと慎重に検討を重ね、証明書の内容に何を加えたらいいのかを検討すべきだろう。オープンな環境下で使用される証明書については、その内容は汎用性を持ったものにしなければならないが、アプリケーションが特定されるのであれば、思い切ってそのアプリケーションに依存してしまうような作りにしてしまって構わないだろう。ただその際には、将来的にその証明書がほかのアプリケーションで利用される可能性があることも十分検討しなければならない。
C社のように、配布先を管理しているデータベースの体系に合わせた形で、そのエントリを特定するのに十分な情報を格納しておくというのが妥当なところではないだろうか。
●証明書発行フロー
先に述べたように、C社ではすでに取引先に対する契約締結から取引先管理データベースへの登録までのフローが存在する（図2）。このフローに証明書発行の流れをいかにうまく乗せるかというのが重要なポイントになる。
C社では、基本契約を締結する前に対象となる会社の審査を行い、契約してよいかどうかを見極める。その後、契約の締結、そして取引先管理データベースへの登録を行うわけだが、その際に電子調達システムの利用を希望するか、そして希望するのであれば、証明書が何枚必要なのかを申込書に記入してもらう。資材調達部門はその申込書をチェックし、情報システム部門に送付するとともに、証明書発行手順を取引先に対してアナウンスする。取引先はWebブラウザを使用して証明書の申請を行い、情報システム部門は資材調達部門から受け取った情報を基に証明書申請の正当性を審査し、証明書の発行を行う。取引先はWeb経由で証明書をダウンロードする（図3）。
ここでポイントになるのは、取引先との窓口を資材調達部門に一本化し、問い合わせの対応などを除いては情報システム部との直接のパスを作らないことだ。これによって、窓口が複数あることによる取引先の混乱を防ぐことができるとともに、証明書の発行についての情報を、業務の主幹部門である資材調達部門が把握することが可能になる。このように情報システム部門だけでなく、業務の主幹部門をいかに巻き込むかということが、後々のトラブルを少なくする条件だといえるだろう。
●証明書の有効期間
基本契約書の存在は上記に説明したとおりだが、C社ではこの基本契約書の有効期間を2年間と定めていた。そして、発行する証明書の有効期間もこの基本契約書の有効期間と合わせることとした。これにより、契約の更新と同時に証明書の更新作業をすることになり、業務フローが作成しやすいからだ。
●既存取引先への証明書発行
新規に登録する取引先や契約の更新時期を迎える取引先については、上記の業務の流れに乗せて証明書を発行すればよいのだが、そのほかの既存取引先については、別途証明書を発行／配布する手段が必要だ。
まずそのために、既存取引先に対して電子調達の使用を希望するかを確認し、もし希望するのであれば証明書は何枚必要か、といった情報を集めることにした。その後、対象となる取引先の情報を取引先管理データベースから抽出し、それを元データとして証明書要求ファイルを作成する。この要求ファイルを読み込んで証明書を一括発行するバッチプログラムを用意することで、“かぎ”や証明書の一括生成が可能になった（図4）。生成／発行されたかぎと証明書は、PKCS#12ファイルの形でFDに格納し、取引先に配布することとした。
●証明書の配布と責任
先ほども述べたように、電子調達において“認証”すべきなのは、「正規の取引先のしかるべき担当者である」ということだ。ただし、この「しかるべき担当者」を把握するところまで認証局が責任を持つことは非常に難しい。担当者の個人名や住所を送付してもらい、その住所に証明書を発送するというようなやり方をすれば不可能ではないのかもしれないが、このビジネスのモデルにはまったくマッチしない。
そこで認証局側は、「しかるべき取引先」へ証明書を発行することを確実に保証し、その先の「しかるべき担当者」への証明書の発行／配布については、取引先に責任を持ってもらうという形をとった。これにより、取引先の担当者が変更されることがあっても、取引先が責任を持って証明書を引き継ぐような形をとることができる。もちろん、これに伴うリスクもある。取引先の旧担当者が、かぎをコピーして持ち出してしまうというリスクだ。これについては、もしかぎ管理をしっかり行う手段がないのであれば、担当者が代わる際には必ず旧担当者が使用していた証明書を失効し、新しい担当者用の新しい証明書を発行する、という形もとれるようにしておくのである。
このように、取引先に対して責任を負ってもらう形をとりながら、取引先がその責任を全うできるような選択肢も用意しておくことが重要だ。
その他に考慮すべきポイント
●CPSを作成すべきか？
C社のケースでは、以下のような理由からCPS（Certificate Practice Statement：認証局運用規程）の作成は不要だろう。
(1) 証明書の発行対象がC社の取引先に限られている
(2) 証明書発行自体がサービスとして独立しているわけではなく、あくまでも電子調達の付加的なサービスである
つまり、証明書の発行を受けようとする側が、認証局の運用方法やセキュリティレベルを判断材料にして、証明書発行を受けるか否かを判断するものではないからだ。しかし証明書の発行を受けることで、それに伴う責任が発生するし、万が一の場合の保証についての取り決めなどは別途行っていかなければならない。取り決めについては、基本契約書中にこれらの内容を盛り込んでおく方法や、別途電子調達に関する約定を作成し、取引先に配布しておく方法などが考えられる。
●アプリケーションとの連携
電子調達を行う際、最初から自分たちでアプリケーション・システムを構築することもあれば、市販のパッケージを利用してアプリケーションを構築する場合もあるだろう。いずれにしろ、取引先管理データベースを利用してアプリケーションが動く形になる。SSLクライアント認証の場合には、連載の第3回目（「身近なPKI〜SSLを理解する」）でも書いたように、証明書に記述されている情報をWebサーバ配下のアプリケーションで取得することが可能だ。この情報をアプリケーション側で取得できれば、取引管理データベースとのシームレスな接続が可能になる。
●電子調達における電子署名の適用の可能性
電子調達の中では、主に受発注のトランザクションが数多く飛び交うことになる。C社のように、システムの入り口での認証と通信の暗号化という目的でPKIを導入するのは一番手っ取り早いし、かつ効果的な利用だといえるだろう。しかし、トランザクションへの電子署名についてはSSLのレベルでは行われない。これまで、注文書や請求書といった書類に対して社印による押印がなされていたことを考えると、その法的な根拠は若干希薄になっているといえるだろう。
ただ、各トランザクションに電子署名データを付加するには、越えなければならないハードルがある。まず挙げられるのは、電子署名法の適用が難しいということである。連載の第4回目（「ECを加速する電子署名法 」）でも触れたが、電子署名法ではあくまでも自然人（個人）を対象としたものであり、「法人」や「法人に属する個人」の認証には適用されない。ただ、紙ベースでやりとりされているときも、印鑑登録されている代表者印をすべてについて押印しているわけではないので、ここは考え方次第だろう。
もう1つのハードルが、署名アプリケーションの実装だ。SSLベースでPKIを実装するのであれば、必要な機能はすでにWebブラウザやWebサーバに実装されている。だが、電子署名についてはそうはいかない。電子署名の機能を備えたEC用のパッケージソフトは現在非常に限られており、電子署名の付加およびその検証については、ほとんどを自分たちで作り込まなければならない。市販のツールキットを使ってある程度作り込みの負荷を減らすことは可能になるが、それでもPKIの専門的な知識を持った技術者が必要になってしまう。いまだ電子署名についての適用事例が少ないのは、実はこのような技術者の不足に起因するところが大きい。
実運用までの課題
ここで、もう一度ポイントをおさらいしておこう。
- 証明書発行にかかわる審査は、取引先との契約締結時の審査をもってこれに代える。担当は資材調達部門
- 証明書の申請は、資材調達部門からの情報に基づいて取引先がWeb経由で行う
- 申請者の妥当性は、資材調達部門からの情報を基に情報システム部門において行う
- 証明書は取引先の担当者が直接ダウンロードを行う
今回の場合、取引先の担当者がWebで申請を行い、Webで証明書をダウンロードし、最終的にその証明書を使用して電子調達のアプリケーションを使用する。ただし、現在のWebブラウザの実装においては、PKI関連の機能は決して分かりやすいものとは言い難い。PKIをまったく知らない人が使うことを想定していないのだ。C社に限らず、調達における取引先には中小の企業が多く、コンピュータのリテラシが高い企業ばかりとはいえないのが実情だろう（画面1）。
C社では、このようなことを考慮して、各取引先を対象とした電子調達に関する説明会を行うこととした。ここでは、電子調達のアプリケーションの使用方法の説明とともに、電子証明書の申請方法や取得方法、認証時の使用方法などを説明することとした。
まだPKIや電子証明書の使用が一般的であるとはとてもいえない現在において、上記のような説明会の実施やサポート窓口の開設、マニュアル類の整備など、使用者に対するケアは重要なポイントになるだろう。
Copyright © ITmedia, Inc. All Rights Reserved.