利用者環境の安全性のためのPKI

3.3. 業務システムにPKIを適用した場合の課題 | 3.5. PKIに関するその他の課題

3.4. 業務システムにおけるPKI利用の解法

前節では、業務システムにPKIを取り込む際にはクライアント証明書の管理方法が課題になることを説明しました。ここでは、その課題の解決方法の一例を紹介します。


3.4.1. 物理的なデバイスへの証明書の結び付け

証明書と私有鍵は物理的実体を持たない電子的な情報ですが、それゆえ管理・運用が難しくなってしまっています。そこで、電子的な情報である証明書と私有鍵を何等かの物理的なデバイスに結び付けることで、管理・運用の難しさを軽減することができます。つまり、証明書の配布や管理を、物理的なものの配布や管理のメタファーで扱います。会社内では指揮命令系統が整備されていますから、配布や管理をこれに準じて行うことができるようになります。証明書と私有鍵を結び付けることができる物理的デバイスにはいくつかの種類があります。


鍵生成機能を備えるセキュリティトークン

このデバイスは、証明書や私有鍵の保持のみならず、私有鍵の生成(正確には公開鍵との鍵ペアの生成)もデバイス内部で行うことが可能です。したがって、私有鍵がデバイスの外に出ることがなく、非常に安全であると言えます。安全を重視する場合はこのタイプを考えてください。ただしコストは高いです。USB接続のものやICカードタイプのものがあります。


鍵を安全に保持できるセキュリティデバイス

パスフレーズ認証や生体認証を用いてデバイス内部に保持された私有鍵を保護することができるデバイスです。方式によりますがコストは中程度です。鍵生成機能を持たないため私有鍵を外部で生成してデバイスに格納するという手順が必要になり、鍵や証明書の格納までの安全性確保など運用の設計も重要になります。


鍵の安全性を別途確保するデバイス

PKIとは別の仕組みで鍵の安全性を確保したデバイスです。一般に低コストとのデバイスと組み合わせます。

デバイスはクライアント数分必要ですから、コストには大きく響きます。一般的には安全性とコストはトレードオフになります。導入にあたっては必要とされるセキュリティの強度とコストのバランスを見極めることが重要です。


3.4.2. 証明書の発行および配布方式の選択

実システムにおいては証明書の作成主体が誰になるかを運用を含めて検討しなくてはなりません。以下の方法が考えられます。

方式概要
クライアント個別作成クライアントで個別に鍵生成および証明書発行要求(CSR)作成を行い、CAで署名した証明書を再度クライアントに配布する。
センター一括作成センター(CA側)で一括してクライアントごとのの鍵ペア生成および署名済み証明書の作成を行い、私有鍵と証明書を各クライアントに配布する。
両者の組み合わせ最初の証明書の作成のみはセンター一括作成方式で行い、二回目以降は証明書の有効期限内にクライアント個別作成方式で行う。

鍵の安全性を重視すれば、私有鍵が持ち主であるクライアント以外に知られないように鍵生成はクライアント側で行うのが適切です。その観点では、クライアント個別作成方式が望ましいことになります。しかし、クライアント個別作成方式ではCSRの発行者が本当に証明対象者かどうかを確認する必要があり、PKIの仕組みの範疇を超えた認証機構が必要となってきます。

この問題を回避するため、証明書の作成まではセンター側で行い各クライアントに配布するセンター一括作成方式をとる場合もあります。この場合には鍵をセンター側で生成することになりますので、クライアントに私有鍵を安全に配布するための仕組みや配慮が必要になります。その一つの方法として、物理的デバイスを用いる方法があります。私有鍵を安全性が確保された物理デバイスに格納して、それを物理的に安全な手段でクライアント(ユーザ)に手渡すことができれば、私有鍵が安全に配布できることになります。

また、前出両方式のメリットを活かすことができる組み合わせ方式も一つの選択肢です。最初の配布をセンター一括作成方式で行うことで、クライアント個別作成方式が抱える認証機構の問題を回避することができます。また、証明書の更新については現証明書の有効期限内にクライアント個別作成方式で行うことにより、センター一括方式が抱える私有鍵配布の問題を回避しつつ、認証機構の問題も回避することができます。現証明書に対応付けられた私有鍵でCSRを署名すれば、特別な認証機構がなくともクライアントの認証になるからです。ただし、組み合わせ方式も万能ではなく、現証明書の有効期限内に手続きを終えられない場合の対処が必要となります。


3.4.3. クライアント証明書の有効性確認

PKIには証明書の有効性確認のための仕組みは定義されていますが、クライアント認証に証明書を用いる場合にはあまりそれにとらわれない方がよいでしょう。実システムにおいてはユーザ(=クライアント)の認証と権限管理はセットとなっていることが多く、そのための機構も整備されているはずです。証明書の有効性確認をこの機構の枠内で処理することが合理的な場合もあります。

そもそもアカウント管理が独立して管理されている場合もあるでしょう。この場合クライアント証明書は認証のための手段となりますので、有効性確認はアカウント管理との連携と捉えて設計すればよいのです。


3.4.4. PKI適用以外の選択肢の再考

業務システムにおいてはクライアントを完全に把握できていますので、見知らぬ第三者同士がCAを媒介に信用の輪をつなげるという目的のPKIの機構は、過大である場合が多くあります。一方でPKIのソフトウェア的な整備は進んでおり、新たなクライアント認証の仕組みを作るよりも既にあるPKIの枠組みを採用する方が返って簡単な場合もあります。PKIの導入にあたっては何を・どの程度の強度で・どの程度のコスト(費用・運用)をかけるかかというバランスを見極めることが大変重要です。場合によっては、公開鍵暗号ベースでの独自機構を設計することも考えられます。PKIは一つの手段ととらえ、全体として最適なシステムを考えましょう。

無料小冊子のお申込みはこちら

株式会社システム計画研究所のオフィシャルサイトはこちら

当サイトへのご質問及び安全・安心・信頼のシステム開発に関するご相談はこちら

通信・ネットワークシステムの開発マネージメント情報サイト「通信・ネットワークシステム開発.COM」はこちら

サーバ監視・ネットワーク監視ツール isNetSentry-S のサイトはこちら