第2回 導入プランを立てよう!


池谷千尋
ネットマークス
2001/11/1
 連載ロードマップ

第1回 電子署名で何が変わる?
第2回 導入プランを立てよう!
第3回 電子署名導入プラン サーバ編その1
第4回 電子署名導入プラン サーバ編その2
第5回 電子署名導入プラン クライアント編


 前回は電子署名の意味と、それにより実現できることを説明したが、今回は実際にPKIの利用を検討する際に考慮すべき点や導入ステップについて解説してみたいと思う。

   目的から見極めるPKIとCA選択のポイント

  PKIを導入するに当たって、CA(認証局)*1の利用形態を選択するには何を基準にすればよいのか? コストが最優先であったりインハウスでPKIを構築することが最優先課題であったりする場合もあるが、利用目的・用途を明らかにし、それに合ったCAを選択するのが最も有効であろう。

●利用目的の明確化

  まずは、PKIの利用目的・用途を明確にすることが、導入を進める第一歩となる。PKIの用途としては以下のようなものが考えられる。

  • メールの暗号化/署名
  • Webサイトのセキュリティ
  • Webサイトへのアクセス制御
  • VPN機器間の認証
  • VPN接続のためのリモートクライアント認証
  • 電子申請に利用する申請書の署名
  • 電子商取引に利用する認証/署名

 このような利用目的・用途をはっきりさせることによりCAが何を保証すべきなのかが見えてくる。 PKIにはさまざまな要素や機能があるが、すべての要素/機能がおのおのの用途に必要なわけではない。

 

*1 鍵と証明書のライフサイクル管理を行う共通鍵暗号とデジタル署名により成り立つものがPKIシステムであり、CAを含むRA(登録機関)、証明書の保管、証明書失効システムなどの基本要素を含んだものと定義することができる。


 各目的・用途に必要な要素/機能を示したものが表1である。


目的・用途

要素
機能

メール

共有または互いのルート証明書
認証、完全性、秘匿性

Webサイトの暗号化(SSL2.0)

ブラウザが持つルート証明書
認証、完全性、秘匿性

Webサイトの認証化(SSL3.0、TLS1.0)

共通ルート証明書
証明書失効
認証、完全性、秘匿性

VPN機器

共通のルート証明書/相互認証
証明書失効

認証、完全性、秘匿性

電子申請

証明書失効、相互認証
認証、完全性、タイムスタンプ
秘匿性、公証
電子商取引
証明書失効、相互認証
認証、完全性、秘匿性
否認防止、(タイムスタンプ)
表1 PKIの用途ごとに必要な要素


●利用対象

 次に利用範囲を考える。これにより証明書の発行対象および規模がどの程度であるかを見極めることができる。対象者を考える前にまずはPKIにかかわる当事者の役割と関係を整理してみたい(図1)。

 

図1 発行者(CA)/利用者/信頼者の役割りと関係

 

  • 発行者
    認証局(CA)および登録局(RA)、発行局(IA)を指し、発行する証明書の内容についての責任を持つ。
  • 利用者
    証明書を利用する人を指し、発行者が証明書を発行する対象となる。
  • 信頼者
    利用者が証明書を使用して、実際に通信(取引)する相手を指す。
    信頼者にとっては、発行者(証明書)を信頼できるか否かが、通信(取引)する際の判断となる。

 利用目的によりCAの形態を選択する場合、まず証明書を利用する相手や配布する範囲を考慮する必要がある。

●証明書の送信対象

 だれに証明書を発行するのか? だれに信用してほしいのか?

  • 社内、組織内のメンバー
  • 取引先
  • あるグループ内のメンバー(組織のつながりのないメンバー)
  • 不特定の人

●PKI対応アプリケーション

 デジタル署名の応用アプリケーションを考えると、一般に新たな開発を加えずに署名機能が利用できるアプリケーションは非常に少ない。PKIに対応した一般ユーザー向けアプリケーションとしては以下のものがある 。

種類 アプリケーション名
メールソフト Webブラウザ付属のメールソフト(Microsoft Outlook Express、 Netscape Messenger)
そのほかのS/MIME対応メールソフト(Orangesoft Winbiff、アライドテレシス AT-承認メール、i4 SecureMessenger)
Adobe Acrobat pdfファイルの署名(ベリサイン、Entrust Enterprise証明書に限られる)
Accelio FormFlow   XMLへの署名機能および検証機能
Microsoft Windows XP + Office XP   Windows XP環境下のOffice XP製品で作成したファイル単位の署名
表2 デジタル署名が利用可能なアプリケーション

●CAの信頼とは?

 証明書を持った相手やその発行元のCAを“信頼”するということは果たしてどういうことなのだろうか?

  1. 自分が信頼するCA
     自分が信頼するCAとは、「自分の証明書の発行元」あるいは「自分の証明書の発行元と相互認証されているCA」、「自分の証明書の発行元とルートがつながっているCA」である。このほかにもブラウザなどには最初から“信頼できるルート認証機関”が埋め込まれている(画面1)。これはおもに、Webサイト証明書で利用されており、当該Webサイトが認証機関により確認されているので、実在性について保証されているという意味である。しかし、だからといってそのままそのCAを信頼するかどうかは利用者の責任で行われることに変わりはない。ただ、期待されている効果としては住所、電話番号およびクレジット番号などを送信する際の通信経路の暗号化といった意味合いが強い。


    画面1 信頼できるルート認証機関

  2. 信頼できる相手
     証明書を持っているユーザー(エンドエンティティ:利用者と事業者を総称したもの)同士で相手を信頼する場合はどうだろう。お互いを信頼しあうということで両方が証明書を持つことになる。そして証明書を提示されたときに相手を信頼するには以下の方法がある。

(1)Webモデル(Webサーバとブラウザの関係)
ブラウザに組み込まれた「ルートCA」は暗黙的に信頼済みのCAということになる。しかし、この場合は自分自身のデジタル証明書の発行元CA とブラウザに組み込まれたルートCAと「信頼のパス」がつながらない場合でも信頼するものとしてあつかわれているのが現状である。

ブラウザに組み込まれたルートCAは暗黙の信頼

図2 CAのモデル(Webモデル)

(2)自分の持っている証明書の発行元と相手の証明書発行元との間の信頼の連鎖をたどり、パスがつながっていることを確認する。

 代表的な例では、階層構造モデル(図3)と相互認証モデル(図4)がある。


証明書の利用者と信頼者が同一のルートを持っているケースで単一のツリーに集約される
図3 CAのモデル(階層構造モデル)

 

証明書の利用者と信頼者はそれぞれ異なったCAのルートを持ちツリーも異なるが、CA間で相互認証することにより”信頼のパス”を形成する
図4 CAのモデル(相互認証モデル)

 

   PKIの「構築」が目標ではなく、「利用」が目標

 さて、いよいよPKIの導入に入ることにする。導入のステップを以下のように考える。PKIの構築が目標ではなく、PKIを利用することを目標におく。  

Step1
サービスの検討 ・PKI導入基本方針策定
・サービスモデルの明確化
・コストと利益の把握
・サービスインまでのマスタースケジュール
Step2
システム設計 ・サービス形態の選定
  (インハウス、アウトソース、外部サービス)

・ セキュリティ要件
Step3
運営設計 ・証明書ポリシー/運用規定の検討
・運用手順、体制の整備
・業務フローの検討
Step4
導入 ・PKIシステム構築/証明書取得
・物理的セキュリティの構築
・システムテスト
Step5
運用 ・スタッフへの教育
・セキュリティレビュー
・システム監査
表3 PKI利用の導入ステップ

●ヒューマンリソースなどの検討項目

  PKIを利用するうえでインハウスで構築するかアウトソースを利用するか、 第三者機関のサービスを利用するか、利用目的や対象を考慮して決めるべきだということを述べたが、もう1つ重要な点がある。構築/運用にかかわるヒューマンリソースをアサインできるかどうかである。

 第1回の記事で初期構築費用の目安として“非常に乱暴ではあるが”とお断りしたのは、実は構築に関わるヒューマンリソースの部分や運用コスト、設備コストが含まれていないためである。

●サービスの検討

 PKIシステムをどのようにビジネスに組み込むのか基本的な戦略を立てる必要がある。

  • ビジネス要件、基本方針策定
  • サービスモデルの明確化
  • サービス対象と範囲の決定
  • コストと利益の把握
  • サービスインまでのマスタースケジュール

●システム設計

 必要なシステムの検討および設計を行う。サービス形態の選択においては運用設計と並行して進める。運用方法はPKIシステムと密接に連携するため双方を関連付けながら検討することが求められる。

  • サービス形態の選定(インハウス、アウトソース、第三者機関のサービス)
  • 電子認証システム機能設計
    PKI利用システム、アプリケーションとの連携などを検討する。
  • セキュリティ要件検討
図5 CA形態:インハウス

 

図6 CA形態:アウトソーサ(アウトソース、第三者機関のサービス)

 

●運用設計

 運用の検討を行う。インハウスでPKIを構築する場合はもちろんのことアウトソースや第三者機関のサービスを利用する場合でも運用を考慮する必要がある。

  • 証明書発行手順(新規、更新、廃棄など)
    証明書のライフサイクルにかかわる手続き、手順を検討する。
  • 運用体制の整備  
    運用にかかわる各役割を実際の組織に当てはめる。
  • CP(証明書ポリシー)の決定/CPS(CA運用規定)の策定

●導入

 ここで、実際にシステムを構築し利用テストを行う。証明書ポリシーやPKI利用モデルに基づいたシステム構築を行うわけだが、アウトソースや第三者機関のサービスを利用する場合PKIプロダクトのインストール、設定などは必要なくなる。ただし、アウトソースや第三者機関のサービスで発行された証明書が目的どおり機能するのか、証明書ポリシーが適切であるかなどを検証する必要がある。

  • インストールおよび設定
  • システムテスト
  • セキュリティ/運用手順のチェック、レビュー

●運用

 運用フェーズにおいては、計画した運用管理に対するチェックを行う。CPSをもって運用している場合には、CPSに準拠した運用がなされていることを確認する意味で監査を受ける必要があろう*2。また、CA運営管理担当者の教育も必要である。

  • 運用管理
    • 各役割分担の機能をチェック、レビュー
    • 業務フローが適切かどうかのチェック、レビュー

  • 監査
    • 監査計画
    • システム監査

*2 「電子署名および認証業務に関する法律施行規則」では、特定認証業務の事業者は指定調査機関の調査を受けるが、これとは別に監査も必要となっている。


   利用モデルの設定

 「電子署名を導入する」という目的で、実際にPKI導入例を次回から紹介していくが、その利用モデルを定めることにする。  

●想定モデル

  1. 目的
    電子署名データの交換および配布
    デジタル署名対応アプリケーションとして広く普及しているメールソフトを利用してのデータ交換
    データ配布にはWebサーバを構築し、そこからダウンロードを可能にする。
  2. 対象者・規模
    第1ステップ:社内の人間同士(数人〜100人以内)
    第2ステップ:社外を含む特定のグループ(不特定多数)
  3. 証明書の役割
    デジタル署名(S/MIME、デジタル署名対応アプリケーション)
    通信経路の暗号化
  4. 必要システム
    メールクライアント環境(Microsoft Outlook Express、Netscape Messenger)
    Webサーバ環境(Microsoft IIS)

●利用するサービス

 ミニマムスタートということで最小限の初期コストを考慮し、アウトソースや第三者機関のサービスを利用する。  

  1. クライアント証明書
    利用者規模が小さいため専用設備は持たない。
    メールの利用は社外の人間も対象になるため、信頼の範囲が組織内に閉じないCAが望ましく、パブリックなサービスを利用する。
  2. Webサーバ証明書
    データ配布対象が不特定多数のため、パブリックなサービスを利用する。

●スケジュール

  1. クライアント証明書の取得
    ブラウザに証明書を格納し、署名付き/暗号化メールの交換を行う。
    デジタル署名対応アプリケーションでの利用とする。
  2. サーバ証明書の取得
    Webサーバを公開しSSL設定を行う。
    署名付きデータの配布を行う。
  3. 利用拡大の検討
    Webサーバの認証(SSL3.0/TLS1.0)設定を行う。
    証明書格納にトークンデバイス(ICカードやUSBキー)の利用をする。

 

 次回は、サーバサイドの導入プランを実際の手続きと手順により紹介する。

 

Security&Trust記事一覧

Index
第1回 電子署名で何が変わる?
第2回 導入プランを立てよう!
  第3回 電子署名導入プラン サーバ編その1
  第4回 電子署名導入プラン サーバ編その2
  第5回 電子署名導入プラン クライアント編


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

注目のテーマ

Security & Trust 記事ランキング

本日 月間