第2回 導入プランを立てよう！
池谷千尋 ネットマークス 2001/11/1 |
|
前回は電子署名の意味と、それにより実現できることを説明したが、今回は実際にPKIの利用を検討する際に考慮すべき点や導入ステップについて解説してみたいと思う。
| 目的から見極めるPKIとCA選択のポイント |
PKIを導入するに当たって、CA（認証局）＊1の利用形態を選択するには何を基準にすればよいのか？ コストが最優先であったりインハウスでPKIを構築することが最優先課題であったりする場合もあるが、利用目的・用途を明らかにし、それに合ったCAを選択するのが最も有効であろう。
●利用目的の明確化
まずは、PKIの利用目的・用途を明確にすることが、導入を進める第一歩となる。PKIの用途としては以下のようなものが考えられる。
- メールの暗号化／署名
- Webサイトのセキュリティ
- Webサイトへのアクセス制御
- VPN機器間の認証
- VPN接続のためのリモートクライアント認証
- 電子申請に利用する申請書の署名
- 電子商取引に利用する認証／署名
このような利用目的・用途をはっきりさせることによりCAが何を保証すべきなのかが見えてくる。 PKIにはさまざまな要素や機能があるが、すべての要素／機能がおのおのの用途に必要なわけではない。
|
各目的・用途に必要な要素／機能を示したものが表1である。
|
|||||||||||||||||||||
| 表1 PKIの用途ごとに必要な要素 |
●利用対象
次に利用範囲を考える。これにより証明書の発行対象および規模がどの程度であるかを見極めることができる。対象者を考える前にまずはPKIにかかわる当事者の役割と関係を整理してみたい（図1）。
 |
| 図1 発行者（CA）／利用者／信頼者の役割りと関係 |
- 発行者
認証局（CA）および登録局（RA）、発行局（IA）を指し、発行する証明書の内容についての責任を持つ。 - 利用者
証明書を利用する人を指し、発行者が証明書を発行する対象となる。 - 信頼者
利用者が証明書を使用して、実際に通信（取引）する相手を指す。
信頼者にとっては、発行者（証明書）を信頼できるか否かが、通信（取引）する際の判断となる。
利用目的によりCAの形態を選択する場合、まず証明書を利用する相手や配布する範囲を考慮する必要がある。
●証明書の送信対象だれに証明書を発行するのか？ だれに信用してほしいのか？
- 社内、組織内のメンバー
- 取引先
- あるグループ内のメンバー（組織のつながりのないメンバー）
- 不特定の人
●PKI対応アプリケーション
デジタル署名の応用アプリケーションを考えると、一般に新たな開発を加えずに署名機能が利用できるアプリケーションは非常に少ない。PKIに対応した一般ユーザー向けアプリケーションとしては以下のものがある 。
|
||||||||||
| 表2 デジタル署名が利用可能なアプリケーション |
●CAの信頼とは？
証明書を持った相手やその発行元のCAを“信頼”するということは果たしてどういうことなのだろうか？
- 自分が信頼するCA
自分が信頼するCAとは、「自分の証明書の発行元」あるいは「自分の証明書の発行元と相互認証されているCA」、「自分の証明書の発行元とルートがつながっているCA」である。このほかにもブラウザなどには最初から“信頼できるルート認証機関”が埋め込まれている（画面1）。これはおもに、Webサイト証明書で利用されており、当該Webサイトが認証機関により確認されているので、実在性について保証されているという意味である。しかし、だからといってそのままそのCAを信頼するかどうかは利用者の責任で行われることに変わりはない。ただ、期待されている効果としては住所、電話番号およびクレジット番号などを送信する際の通信経路の暗号化といった意味合いが強い。
画面1 信頼できるルート認証機関
- 信頼できる相手
証明書を持っているユーザー（エンドエンティティ：利用者と事業者を総称したもの）同士で相手を信頼する場合はどうだろう。お互いを信頼しあうということで両方が証明書を持つことになる。そして証明書を提示されたときに相手を信頼するには以下の方法がある。
（1）Webモデル（Webサーバとブラウザの関係）
ブラウザに組み込まれた「ルートCA」は暗黙的に信頼済みのCAということになる。しかし、この場合は自分自身のデジタル証明書の発行元CA とブラウザに組み込まれたルートCAと「信頼のパス」がつながらない場合でも信頼するものとしてあつかわれているのが現状である。
ブラウザに組み込まれたルートCAは暗黙の信頼
図2 CAのモデル（Webモデル） （2）自分の持っている証明書の発行元と相手の証明書発行元との間の信頼の連鎖をたどり、パスがつながっていることを確認する。
代表的な例では、階層構造モデル（図3）と相互認証モデル（図4）がある。
|
|||||
| 図3 CAのモデル（階層構造モデル） |
|
||
| 図4 CAのモデル（相互認証モデル） |
| PKIの「構築」が目標ではなく、「利用」が目標 |
さて、いよいよPKIの導入に入ることにする。導入のステップを以下のように考える。PKIの構築が目標ではなく、PKIを利用することを目標におく。
|
|||||||||||||||||||||||||||
| 表3 PKI利用の導入ステップ | |||||||||||||||||||||||||||
●ヒューマンリソースなどの検討項目
PKIを利用するうえでインハウスで構築するかアウトソースを利用するか、 第三者機関のサービスを利用するか、利用目的や対象を考慮して決めるべきだということを述べたが、もう1つ重要な点がある。構築／運用にかかわるヒューマンリソースをアサインできるかどうかである。
第1回の記事で初期構築費用の目安として“非常に乱暴ではあるが”とお断りしたのは、実は構築に関わるヒューマンリソースの部分や運用コスト、設備コストが含まれていないためである。
●サービスの検討
PKIシステムをどのようにビジネスに組み込むのか基本的な戦略を立てる必要がある。
- ビジネス要件、基本方針策定
- サービスモデルの明確化
- サービス対象と範囲の決定
- コストと利益の把握
- サービスインまでのマスタースケジュール
●システム設計
必要なシステムの検討および設計を行う。サービス形態の選択においては運用設計と並行して進める。運用方法はPKIシステムと密接に連携するため双方を関連付けながら検討することが求められる。
- サービス形態の選定（インハウス、アウトソース、第三者機関のサービス）
- 電子認証システム機能設計
PKI利用システム、アプリケーションとの連携などを検討する。 - セキュリティ要件検討
 |
| 図5 CA形態：インハウス |
 |
| 図6 CA形態：アウトソーサ（アウトソース、第三者機関のサービス） |
●運用設計
運用の検討を行う。インハウスでPKIを構築する場合はもちろんのことアウトソースや第三者機関のサービスを利用する場合でも運用を考慮する必要がある。
- 証明書発行手順（新規、更新、廃棄など）
証明書のライフサイクルにかかわる手続き、手順を検討する。 - 運用体制の整備
運用にかかわる各役割を実際の組織に当てはめる。 - CP（証明書ポリシー）の決定／CPS（CA運用規定）の策定
●導入
ここで、実際にシステムを構築し利用テストを行う。証明書ポリシーやPKI利用モデルに基づいたシステム構築を行うわけだが、アウトソースや第三者機関のサービスを利用する場合PKIプロダクトのインストール、設定などは必要なくなる。ただし、アウトソースや第三者機関のサービスで発行された証明書が目的どおり機能するのか、証明書ポリシーが適切であるかなどを検証する必要がある。
- インストールおよび設定
- システムテスト
- セキュリティ／運用手順のチェック、レビュー
●運用
運用フェーズにおいては、計画した運用管理に対するチェックを行う。CPSをもって運用している場合には、CPSに準拠した運用がなされていることを確認する意味で監査を受ける必要があろう＊2。また、CA運営管理担当者の教育も必要である。
- 運用管理
- 各役割分担の機能をチェック、レビュー
- 業務フローが適切かどうかのチェック、レビュー
- 監査
- 監査計画
- システム監査
|
| 利用モデルの設定 |
「電子署名を導入する」という目的で、実際にPKI導入例を次回から紹介していくが、その利用モデルを定めることにする。
●想定モデル
- 目的
電子署名データの交換および配布
デジタル署名対応アプリケーションとして広く普及しているメールソフトを利用してのデータ交換
データ配布にはWebサーバを構築し、そこからダウンロードを可能にする。 - 対象者・規模
第1ステップ：社内の人間同士（数人〜100人以内）
第2ステップ：社外を含む特定のグループ（不特定多数） - 証明書の役割
デジタル署名（S/MIME、デジタル署名対応アプリケーション）
通信経路の暗号化 - 必要システム
メールクライアント環境（Microsoft Outlook Express、Netscape Messenger）
Webサーバ環境（Microsoft IIS)
●利用するサービス
ミニマムスタートということで最小限の初期コストを考慮し、アウトソースや第三者機関のサービスを利用する。
- クライアント証明書
利用者規模が小さいため専用設備は持たない。
メールの利用は社外の人間も対象になるため、信頼の範囲が組織内に閉じないCAが望ましく、パブリックなサービスを利用する。
- Webサーバ証明書
データ配布対象が不特定多数のため、パブリックなサービスを利用する。
●スケジュール
- クライアント証明書の取得
ブラウザに証明書を格納し、署名付き／暗号化メールの交換を行う。
デジタル署名対応アプリケーションでの利用とする。
- サーバ証明書の取得
Webサーバを公開しSSL設定を行う。
署名付きデータの配布を行う。 - 利用拡大の検討
Webサーバの認証（SSL3.0／TLS1.0)設定を行う。
証明書格納にトークンデバイス（ICカードやUSBキー）の利用をする。
次回は、サーバサイドの導入プランを実際の手続きと手順により紹介する。
 |
Security&Trust記事一覧 |
|
||||||||||||
- Windows起動前後にデバイスを守る工夫、ルートキットを防ぐ （2017/7/24）
Windows 10が備える多彩なセキュリティ対策機能を丸ごと理解するには、5つのスタックに分けて順に押さえていくことが早道だ。連載第1回は、Windows起動前の「デバイスの保護」とHyper-Vを用いたセキュリティ構成について紹介する。 - WannaCryがホンダやマクドにも。中学3年生が作ったランサムウェアの正体も話題に （2017/7/11）
2017年6月のセキュリティクラスタでは、「WannaCry」の残り火にやられたホンダや亜種に感染したマクドナルドに注目が集まった他、ランサムウェアを作成して配布した中学3年生、ランサムウェアに降伏してしまった韓国のホスティング企業など、5月に引き続きランサムウェアの話題が席巻していました。 - Recruit-CSIRTがマルウェアの「培養」用に内製した動的解析環境、その目的と工夫とは （2017/7/10）
代表的なマルウェア解析方法を紹介し、自社のみに影響があるマルウェアを「培養」するために構築した動的解析環境について解説する - 侵入されることを前提に考える――内部対策はログ管理から （2017/7/5）
人員リソースや予算の限られた中堅・中小企業にとって、大企業で導入されがちな、過剰に高機能で管理負荷の高いセキュリティ対策を施すのは現実的ではない。本連載では、中堅・中小企業が目指すべきセキュリティ対策の“現実解“を、特に標的型攻撃（APT：Advanced Persistent Threat）対策の観点から考える。
 |
|
|
|
|
