特集 PKI導入の手引き

Part.1 PKIを立ち上げてみよう!(2)
〜PKIの設計から運用開始まで〜

内田昌宏
ネットマークス
2000/8/28

3. サービスモデルとサービスレベル

 電子証明書は、通信を行う相手との間で、相互認証を実現するものである。従って図1で示す通り、

図1 証明書のタイプ

  • VPN証明書
    企業間で暗号化通信を行う際に、本当に通信すべき相手かどうかを相互認証するため、各企業に設置されるVPN機器に対して発行される。

  • Web証明書
    Webサーバを使って電子商取引(ECやEDI)を運営する際に、その利用者に対して本当に信頼できるサイト≠ナあるか否かを証明するため、当該Webサーバに対して発行される。

  • クライアント証明書
    個人間で暗号化されたデータ≠やり取りする際の相互認証、または個人が先のWebサーバにアクセスする際のサイト側との相互認証に利用され、個人または端末(ブラウザ)に対して発行される。

の3種類の証明書が、サービスの対象と考えることができる。

 各証明書はその利用形態や利用目的が異なるため、おのおののサービスレベルを検討しなければならない。ちなみにネットマークスでは、

証明書種類
認証対象
申請者
申請手段
審査方法
クライアント証明書 申請者本人 契約者本人
および
所属する組織の管理者の捺印
・簡易書留
・営業手渡し
・署名付き暗号メール
・申請者本人
・所属組織
の監査
Web証明書 申請組織と当該サーバ 管理責任者
組織の代表者印
同上
・申請組織
・ドメイン登録内容の審査
VPN証明書 申請組織と当該VPN機器
同上
同上
同上


4. 証明書にかかわる当事者の関係

 証明書にかかわる全当事者の関係を図2に示す。

図2 証明書にかかわる当事者の関係

  • 運営者
    認証局そのものであり、CA(証明書発行局)とRA(証明書登録局)の両方の機能を備える。

  • 契約者
    認証局と契約を結ぶ法人を指す。Web証明書やVPN証明書では、証明書を発行する対象となる。クライアント証明書の場合は、法人が利用者の証明書を取りまとめて契約する場合がある。この際、契約者は、RA機能の一部(利用者からの申請受付と利用者の審査)を請け負う。

  • 利用者
    クライアント証明書を利用する人を指し、運営者から証明書を発行する対象となる。

  • 信頼者
    運営者が発行した証明書を使用して、実際に通信(取り引き)する相手を指す。信頼者にとっては、運営者が発行する証明書を信頼できるか否かが、通信(取り引き)する際の判断となる。

 仮に証明書が原因で取り引きになんらかの損害が発生した場合は、信頼者から利用者に、利用者から契約者に、契約者から運営者に責任追及(場合によっては損害賠償)が及ぶことになる。従って、利用者は「証明書の管理」について、契約者は「利用者の審査」について、運営者は「契約者の審査」および「証明書発行における運用管理」について、責任を持たなければならない。運営者の責任と義務等を明記したものがCPSである。

 また運営者は、認証局としての瑕疵(誤りや遺漏など)について補償するために、保険に加入しておくことも必要である。保証額や補償の範囲などについては、発行する証明書の目的や用途などを十分に考慮しなければならない。


5. 人員構成の検討

 認証局を運営するにあたっての人員構成を以下に示す。

 これら構成人員は、それぞれ専属とし兼務しないことが望ましい。特にCA管理者とRA管理者は、互いの業務を兼務してはならない。RA機能とCA機能を一人で実行できると、勝手に証明書を発行することができるからである。このように、各役割を分離することで、相互にチェック・監査する仕組みが、認証局の信頼性を高め、同時に発行した証明書の信頼性を維持することになる。


6. 証明書のライフサイクルと鍵管理

 証明書のライフサイクルを図3に示す。運営者(認証局)はこれら「新規登録」「更新」「廃棄」「一時停止」「再発行」の各々に対しての運用ルールを定め、履行しなければならない。

図3 証明書のライフサイクル

 なお各証明書の所定有効期間は、以下が適当と考える。

  • VPN証明書……3年/4年/5年
  • Webサーバ証明書……1年
  • クライアント証明書……1年

 また認証局は、

  • 証明書や失効リストの署名
  • 鍵の暗号化などに利用する秘密鍵・公開鍵ペア
  • 重要な秘密情報を暗号化するための共通鍵
  • 鍵生成の秘密パラメータ

などについて、それらの全ライフサイクルにわたり安全で信頼性の高い鍵管理を実現しなければならない。以下に鍵管理に関する運用例を列挙する。

●鍵の生成
 CAの鍵ペアや共通鍵の生成は、CA運用責任者と2名のCA管理者による管理の元で行い、鍵生成パラメータの確認(鍵長、鍵アルゴリズム)が行われるべきである。

●鍵の保管とバックアップ
 暗号鍵生成システムによって生成された鍵は暗号化された状態で、鍵管理モジュールの専用カードによって保管を行う。暗号鍵保管モジュールのセキュリティレベルは FIPS140-2とする。この際、予備カードへの秘密鍵の格納も行い、その予備カードの秘密鍵はマスタとば地理的に別のセキュアなエリアに保管される。

●鍵の利用
 暗号鍵の利用は、CA管理者がCAセンタ内のセキュアな特定エリア内でのみで使用できる。暗号鍵は、暗号鍵保管モジュールからCA装置に直接読み込んで使用する。CA運用責任者から指名された2名のCA管理者は各々、個別の鍵を持ち、両名がそろわない場合は暗号鍵の利用ができない2名統制の管理を行う。

●鍵の保存
 有効期限が終了した認証局の公開鍵や証明書は20年間の保管を行う。

●鍵の廃棄
 有効期限が終了した認証局の秘密鍵は、秘密情報の露見および残存がないよう、物理的な破壊を行う。認証局の秘密鍵の破壊はCA運用責任者とCA管理者の管理下で行う。

●鍵の定期更新
 認証局の秘密鍵の有効期限は20年とし、利用者に充分な期間を持って更新通知を行う。有効期限が終了する前には、利用者に更新通知を行い、CAの新しい秘密鍵による認証局の証明書を相互認証証明書として発行を行う。

●鍵の危瀕/災害時の復旧
 認証局の秘密鍵の危瀕時、またはその可能性がある場合、対応する証明書の失効を行う。認証局の秘密鍵の危瀕とは認証局から発行された全ての証明書に対して、以下の自体が発生した場合である。

  • 自然災害等で以下正常な管理が不能となる
  • 秘密鍵が漏洩し、偽の証明書が発行される

 認証局の秘密鍵の危瀕は、CAサービス最高責任者の認定を持って行う。CAサービス最高責任者が認定を行えない場合は、CA運用管理者が認定を行う。認証局の失効はCAサービス最高責任者もしくはCA運用管理者の認定を持ってRA運用管理者が行う。

●認証局の公開鍵管理
(1) 認証局は自身の公開鍵を自らの秘密鍵で署名した証明書を作成する。
(2) 認証局の証明書はリポジトリ上にて公開される。
(3) 認証局の証明書はSSL通信をサポートしたWebサーバ上で公開される。


7. セキュリティ対策

 認証機関運営におけるセキュリティを図4に整理した。

図4 各レイヤで必要なセキュリティ対策

 認証局という性格上、技術的・システム的対策だけではなく、物理的対策や運用管理規定など、総合的なセキュリティコントロールが要求される。

Index
特集 PKI導入の手引き

Part.1〜PKIを立ち上げてみよう!
  イントロダクション
 1.PKIとはどのようなものか?
 2.作業ステップを検討する
検討〜導入〜運用まで
 3.サービスモデルとサービスレベル
 4.証明書にかかわる当事者の関係
 5.人員構成の検討
 6.証明書のライフサイクルと鍵管理
 7.セキュリティ対策
  認証実施のフレームワーク
 8.CPS:認証実施規定

次回、実際の「運用編」を公開!



「Master of IP Network総合インデックス」



Master of IP Network フォーラム 新着記事
@ITメールマガジン 新着情報やスタッフのコラムがメールで届きます(無料)

注目のテーマ

Master of IP Network 記事ランキング

本日 月間