有効とは？
|
連載の第2回目（「電子証明書と認証局」）において、「証明書の廃棄」について簡単に述べた。この部分は実際にPKIに接する人々にとって誤解が多い部分であり、ここでもう一度「証明書の有効性」についてクローズアップしていきたい。 まず、証明書の「状態」について説明しよう。証明書は、大きく分けて「有効」と「無効（有効ではない）」状態が存在する。さらに、「無効」状態には「有効期限切れ」「廃棄（失効）状態」「一時停止（失効）状態」の3つのステータスがある。証明書（あるいはその鍵による署名データ）を受け取った側はその証明書が自分の信頼する認証局から発行されているかどうか、ということと同時にその証明書が「有効」な状態にあるかどうかを確認しなければならない。 通常、クレジットカードを顧客が提示した場合、加盟店は当然のことながら自分の店が加盟しているクレジットカード会社から発行されたものかどうかを確認する。さらに、そのカードの有効期限が切れていないかどうかを確認する。有効期限はカードに書かれているので、それを見れば判断できる。そして次にクレジットカード会社に照会をかける。ここで、支払いの遅延があったりカードの紛失・盗難が届けられていたりすれば、そのカードを利用することはできないということになる。 電子証明書の場合もこれとまったく同じである。先ほど述べたように、証明書（あるいはその鍵による署名データ）を受け取ったら、 先に書いたように、証明書にはその証明書の有効期間が書かれている。具体的には「notBefore」として有効期間の開始日が、「notAfter」として有効期間の終了日が書かれている。証明書をハンドリングするアプリケーションは、この領域を見て有効期間内かどうかを判断することになる。 画面1 証明書の有効期間を確認したところ。開始日から終了日までの日付が記されている（画面をクリックすると拡大表示します） 証明書の有効期間は、例えばWindowsのアプリケーションからは画面1のような形で確認できる。また、IEの場合、SSLで接続する先のサーバの証明書が有効期間切れだった場合、画面2のような警告が表示されるようになっている。 画面2 証明書の有効期間が切れていた場合に表示される警告メッセージ（画面をクリックすると拡大表示します） 通常、証明書の発行を受けた者（加入者）は、上記のような事象が発生した場合には直ちに認証局に届け出なければならない。届け出を受けた認証局は、該当する証明書の廃棄作業を行う。 この場合、廃棄の届け出をしたのが証明書の持ち主本人であることを確認しなければならない。何者かが業務を妨害するために本人になりすまして廃棄要求を行っている可能性があるからだ。ただ、鍵が盗難された場合などは緊急性を要するケースもあるので、本人確認がされるまでは下記の「一時停止」のステータスにしておくようなこともありうる。 また、加入者側から届けるのではなく、認証局側が証明書の廃棄を行うことを決定するケースがある。主に次のような要因によるものだ。 いずれにしても認証局は証明書の廃棄オペレーションを行い、その結果として後述するCRLに廃棄された証明書の情報が追加されることになる。 証明書には一時停止（Suspended）というステータスがある。これはどのような場合に使用されるのだろうか。一般的には、以下のようなものが一時停止の要因となる。 ある程度の期間証明書を使用しないことがはっきりしている（例えば、社員証用証明書を長期休暇等で利用しない場合） 1番目の要因は、主に証明書再発行にかかる時間やコストを考慮したものだと考えればよいだろう。例えば、ICカードが見当たらないという状態だが、紛失したかどうか分からない。ただ、ICカードなので再発行するのにコストがかかる、というような場合には、ICカードが紛失・盗難されたのか、あるいは単に家に置き忘れただけなのかがはっきりするまで一時停止状態にしておく、というようなケースだ。 証明書の一時停止の場合も、廃棄の場合と同様に認証局でオペレーションを行い、CRLに「一時停止」というステータスで証明書の情報が追加される。 実際に証明書を発行してもらう加入者や、認証局を運営する側から見た場合、証明書の有効期間は「長ければ長いほどよい」ものだろう。加入者側から見れば有効期限切れに伴う証明書の更新の手続きが必要になるし、認証局を運用する側も定期的に証明書の更新の処理を行わなければならない。いっそ、有効期限なんてなければよいのに、と思われる方も多いのではないだろうか。証明書に有効期間を設定する一番大きな要因は、「暗号技術や鍵の強度」が、永久に確保されるものではない、というものだ。このように、有効期間を決める際にポイントとなるものが幾つかある。それについて見ていくことにしよう。 上記で述べたように、現在安全だといわれている鍵の長さでも、いつかは安全ではなくなる日がくる。問題は何をもって「安全」とするかだろう。各アルゴリズムとその鍵長について、どのくらいコストをかければどのくらいの期間で解読可能か、というようなデータが出ていたりする。例えば、国家予算並みのコストをかければＸ年で解読可能、というようなものだ。ここで、PKIによって守られるものにどのくらいの価値があるのか、ということを考える必要がある。例えば、100万円程度の価値の情報を得るために国家予算並みのコストをかけるものはいないだろう。このように情報の価値を考慮して、鍵の長さや有効期間を決定する必要がある。 証明書に記載されている内容が変更されたら、基本的には証明書を廃棄して再発行する必要がある。例えば社員証用の証明書に部署名を入れたときのことを考えてみよう。もし証明書の有効期間を5年に設定してしまうと、異動が多く発生する毎年4月に多くの証明書を廃棄し、再発行しなければならなくなってしまう。運用を考えるとこれはかなりの負担になるし、また後述するようにCRLのボリュームも大きくなってしまい、それをハンドリングするアプリケーションに大きな負担を強いることにもなりかねない。やはり、このようなケースでは証明書の有効期間は1年間とするのが妥当であろう。このように、証明書の内容に変更が起こる可能性や要因も考慮して有効期間を決めなければならない。 例えば、あるサービスに付随する形で証明書を発行している場合、そのサービスに関する契約が別途存在することが多い。もしこの契約が1年ごとに更新されるようなものだった場合、そのサービスに使用される証明書の有効期間はそれに合わせておくべきだろう。 もう1つ考慮しなければいけない大きな要因は、認証局の証明書の有効期間だ。以前にも述べたように、認証局自身も証明書を持っており、その証明書にも有効期間が存在する。通常、認証局は自身の証明書の有効期限を越えるような証明書を発行することはできない。逆に、認証局の証明書の有効期間を決定するためには、その認証局が発行する証明書にどのくらいの有効期間を設定しなければならないのかを慎重に検討する必要がある。 ここで、証明書廃棄リスト（Certificate Revocation List：CRL）について見てみることにしよう。まず、証明書廃棄リストとは「有効期限を迎えていないにもかかわらず無効となった証明書のリスト」である。ここで重要なのは、有効期限を越えてしまった証明書の情報はCRLには入らない、ということだ。何かの要因で廃棄された証明書の情報がCRLに記載されたとしても、その証明書が有効期限を迎えた時点でCRLからは除外されることになる。 CRLの内容は証明書と同じくX.509で規定されている。主に図1のようなものだと考えればよいだろう。さらに、CRL全体に対してそのCRLを発行した認証局の署名がなされている。 画面3 CRLの内容を確認したところ。ダイアログの名称が「証明書失効リスト（CRL）」となっているが（Revocationの訳し方が違う）、本文中では「証明書廃棄リスト」で統一している（画面をクリックすると拡大表示します） では、実際にCRLのチェックはどのように行われるのだろうか？ まず、CRLは認証局から一定周期で発行される（図2）。CRLを検証したいアプリケーションは以下のいずれかの方法でCRLを自分の環境にダウンロードする。 このほか、認証局がメールなどに添付して配布するという方法もあるが、あまり現実的ではないだろう。 図2 CRLのチェック方法。認証局から発行されるCRLをダウンロードし、クライアント上で該当する証明書の情報を確認する 自分の環境にCRLをダウンロードしたアプリケーションは、取得した証明書の情報がないかどうか、CRLをサーチする。ここで問題点が2つある。 アプリケーションが証明書廃棄の確認を行う必要があるとき（つまり、署名付きトランザクションデータを受け取ったとき）に、毎回CRLをダウンロードするというのは、（アプリケーションの性質にもよるが）現実的ではないだろう。ネットワークのトラフィックも問題だし、CRLの検証自体にかかる時間が大きくなってしまう。CRLのサイズが大きくなれば問題はさらに大きくなる。 CRLには「次回CRLを発行するのは何月何日の何時何分の予定です」という情報が入っている。通常、認証局側は12時間に1回程度の周期でCRLを発行し、アプリケーション側は自分の環境にダウンロードしてあるCRLの「次回発行予定日時」をチェックして、それを過ぎていたら新しいCRLをダウンロードするような形で実装することになる。このとき、あまり発行周期を短くしてしまうとCRLのダウンロードが頻発することになってしまい、あまり長くすると廃棄がされてからCRLに反映されるまでのタイムラグが長くなってしまう。このタイムラグが長ければ長いほど、例えば盗まれた鍵を使用して不正が行われるリスクが高くなってしまうということになる。 画面4 CRLには次の発行予定日時が記されている（画面をクリックすると拡大表示します） 次の問題がCRLをサーチする時間だ。CRLによる証明書の有効性の検証は、「バッチ的な」処理といわざるを得ない。アプリケーションは、自分の環境にダウンロードしてあるCRLを頭からサーチして、検証したい証明書の情報が存在するかどうかを確認する。CRLのサイズが大きくなればなるほどこのサーチにかかる時間が多くなってしまう。オンライントランザクションを処理するようなアプリケーションの場合、これが大きな問題になる可能性が高い。 このような問題を解決しようとする1つの考え方が「デルタ（差分）CRL」というものだ。簡単にいうと、すべてのCRL（これをベースCRLという）を週に1回程度発行し、あとはこのベースCRLとの差分のCRLのみを発行する。これによってアプリケーションがダウンロードしなければならないCRLのサイズを小さくすることができる。ただし、検証するためにはベースCRLと差分CRLを合わせたものをサーチしなければならず、また一定間隔でファイルをダウンロードしなければならないという点は基本的には変わらない。 証明書には、CRLの置いてある場所を示すための領域がある。CRL配布点（CRL Distribution Point）がそれだ（画面5）。これにより、アプリケーション側がCRLの場所を固定的に持つ必要がなくなるばかりでなく、CRLをある単位で分割し、それぞれ異なる場所に置くことが可能になる。例えば、複数のサービス向けに証明書を発行している認証局の場合、そのサービスごとにCRLを分割し、異なる場所に置くとともに、それぞれの証明書のCRL配布点にその置き場所を示しておく（図3）。各サービスのアプリケーションは、自分と関係のないサービス用の証明書の廃棄情報まで含んだCRLをダウンロードしたりサーチしたりしなくてもよくなるのだ。 図3 CRL配布点の利用により、自分と直接関係のないサービス用の証明書の廃棄情報までをも含んだCRLをダウンロードしなくてもよくなる ここまで見てきたように、CRLを使用した証明書の検証は、オンライントランザクションにおけるモデル、特にクライアントサイドで証明書の検証を行わなければならない場合には、あまり向いていないといわざるを得ない。それに対応しようとしているのが、OCSP（Online Certificate Status Protocol）というプロトコルと、それを実装したOCSPレスポンダである。CRLを使用した証明書検証がバッチ的であるのに対し、この仕組みはまさにオンラインの世界で証明書の検証を行う仕組みだ。 図4 OCSPの仕組み。OCSPレスポンダと呼ばれるサーバが仲介することで、クライアントは必要な情報をOCSPレスポンダに問い合わせることで入手できる OCSPレスポンダといわれるサーバは、まずCRLを自分の中に取り込んでおく。証明書の有効性を検証するアプリケーションは、その証明書のシリアル番号をOCSPのプロトコルに載せた形でOCSPレスポンダに送る。すると、それに対するレスポンスとしてその証明書が廃棄されているかどうかをアプリケーション側に返してくれるのである。その際、OCSPレスポンダがボトルネックになってしまっては意味がないので、通常はCRLのサーチを高速化するような仕組みが実装されている。これにより、アプリケーション側に証明書を取り込む必要がないし、アプリケーションが自分でCRLをサーチする必要もない。さらに、CRLはOCSPレスポンダのみが入手すればよいので、OCSPレスポンダがCRLを入手する経路のみをうまく設計してやるだけで、CRLのやりとりにかかわる通信のオーバーヘッドを考慮する必要がなくなり、結果としてCRLの発行周期も短くできるのである。 最近では、「証明書パスにおける検証（Path validation）」にどのように対応するか？ という問題が論点になっている。「証明書パス」とは何だろうか。連載の第2回目（「電子証明書と認証局」）で、認証局の階層構造について説明した。認証局をさらに認証する上位の認証局が存在するということだ。このように認証局が階層化されていると、エンドユーザーの証明書の検証とそれを発行した認証局の証明書の検証、さらに上位の認証局の証明書の検証……というように、異なるOCSPレスポンダに対してアプリケーションが幾つもの問い合わせを投げなければならなくなってしまう（図5）。同じことが、相互認証（認証局と認証局がお互いに認証しあうことによって、信頼の幅を大きくすること）の場合でも発生する。 このような制御をアプリケーション側に強いるのは問題ではないかという議論があり、現在ではOCSPの拡張としてDPV（Delegated Path Validation Protocol）という新たなプロトコルが考案され、インターネット上でドラフトとなっている。 ここまで述べてきたように、証明書の廃棄情報を検証するための仕組みは現在のところこれといって決め手がないのが現状だ。今後も、新たな仕組みが標準化される可能性は十分にある。ただ、PKIのモデルによってはCRLのハンドリングで十分な場合も多くあるだろうし、Path validationを必要としない場合も多いであろう。要は、自分たちがとろうとしているPKIのモデルに何が一番適しているかを検討し、選択していくのが賢明だといえるのではないだろうか。 OpenIDをとりまくセキュリティ上の脅威とその対策 （2007/11/20） さまざまなWebサービスが対応を表明し、より身近な技術となったOpenID。ところで、OpenIDのセキュリティ対策はどうなっているのでしょうか トラブルシューティングはCentOS 5におまかせ （2007/11/15） リリースから半年が過ぎたCentOS 5、もう使っていますか？ これにはSELinuxの運用をもっと楽にしてくれる便利なツールが追加されています ヘルスチェックしてる？ 怠ってはならないDNSのケア （2007/11/9） DNSやDHCP、安定稼働しているからといって放っていたりしませんか？ ネットワークを支える要となるサービスにもう一度注目しよう 脆弱なホストを狙った不正中継を見抜く （2007/11/7） 攻撃者は設定ミスや脆弱性を残しているマシンへどのように攻撃してくるのか？ 踏み台にされないために、その見抜きかたを知っておこう ホワイトペーパー利用者に「Amazonギフト券」を抽選で100名様にプレゼント！――TechTargetジャパン リニューアル・キャンペーン ＠ITトップ｜Security&Trustフォーラム トップ｜会議室｜利用規約｜プライバシーポリシー｜サイトマップ |
[ 153] 証明書の有効性
[引用サイト] http://www.atmarkit.co.jp/fsecurity/rensai/pki05/pki01.html
|
企業システムが有効活用されているかどうか──。古くからある情報システムの大きな課題だ。システム監査という観点では、それをどのように見るのだろうか。（→記事要約へ） 」は、情報システムを安心して使えるかどうか、という信頼性と安全性の監査について、お話ししました。 しかし、システムは安心して使えれば十分かというと、企業経営という視点に立つと、それだけでは十分ではありません。システムの構築・運用には相当の投資が必要であり、投資に見合う価値をシステムが提供できるか、提供しているかは、ユーザー企業の経営者にとって非常に重要な問題です。 経済産業省の「システム監査基準」では、「システム監査は情報システムの信頼性、安全性、効率性の向上を図ることを目的に実施する」としており、効率性については、次のように定義しています（表1）。 この定義の前半の「資源の活用度合」は、狭い意味では、ハード、ソフト、ネットワークのシステム構成要素を無駄なく利用しているかということです。そうした視点も必要ですが、広くとらえると、企業活動の中でシステムを有効活用して、企業活動の付加価値を高めているかということです。それが、定義の後半の「費用対効果の度合」にも通じます。システムを有効活用することができれば、費用対効果は当然高くなります。 会計学の世界で、「3E」と呼ばれている考え方があります。投資と効果の関係について整理を行った考え方です（図2）。 インプットからアウトプットへの処理プロセスに焦点を置いている 3Eは経済性、有効性、効率性の英語でのスペルがすべて“E”で始まることから、そう呼ばれています。経済性は投資に注目した考え方、つまり、100万円で構築した販売管理システムと200万円で構築したものとでは、前者の方が経済性に優れているという見方です。 有効性は効果に注目した考え方であり、販売管理費比率を10％削減できた販売管理システムと20％削減できた販売管理システムでは、後者が有効性では勝っているという見方です。 最後に効率性ですが、投資から効果を生むプロセスに注目します。100万円を投資して構築し販売管理費比率を10％削減できた販売管理システムと、200万円の投資で20％の販売管理費比率削減を実現した販売管理システムで、どちらが効率性が良いかということです。これは数値だけでなく、その中味を分析・評価しなければ判断できません。 会計学における3Eは、概念的には分かりやすいものでしょう。情報システムの投資対効果を考えるときには、3つ目の効率性に着目して評価する必要があります。「投資効果性」「採算性」と呼ばれる視点であり、今日では、これが情報システムの有効性の重要な視点の1つとなっています。 情報システムの有効性については、投資対効果以外にもさまざまな視点があります（表3）。 要は、情報システムが企業活動において、どれだけ役に立っているか──経営者の経営上の意思決定、管理者の計画策定・実績評価・判断、業務担当者の業務遂行にどれだけ貢献しているかということです。さらに、現在の情報システムがどうかということだけでなく、経営戦略との整合性が取れた情報戦略、情報化計画、システム化計画が策定・推進されているかという「戦略性」も重要になります。 前回取り上げた信頼性や安全性に比べて、明確な監査基準が設定しにくく、監査手続きも確立しにくい分野です。 経営戦略から情報戦略、情報化計画、システム化計画、それに基づいたシステム構築という基本的な流れがあります。まずは、その流れに従って情報化が進められているかという評価が必要です。経済産業省の「システム監査基準」は、この流れを基準項目として設定しています。企業によって違いはありますが、有効性の高い情報システムを実現するためには、この基本的な流れが重要であり、ヒアリングや記録の確認によって、この基本的な流れに沿って情報化が進められていることを確認します。 構築されたシステムが有効かどうかは、それを利用する人たちが、いかに満足しているかということです。経営者、管理者、担当者、さらに対象を広げて株主、取引先、顧客など、システムに関係している人たちに、確認すべき項目を明確にしたうえで話を聞く方法が、原始的かもしれませんが、最も一般的な監査手続きです。場合によっては、アンケート調査によって幅広く意見を集める方法も有効です。 話を、投資効果性に戻します。投資効果性についてのシステム監査では、どんな点について監査するのでしょうか？ 上で述べた基本的な情報化の流れは、そのまま、情報化投資とその評価の流れにもなります（図4）。 情報システムの投資効果性の評価とは、図4の流れに沿った取り組みが企業活動の中で行われており、結果として経営目的に合った投資対効果の目標が達成されているかを評価することです。投資対効果の目標が達成されているということは、その情報システムが企業活動に貢献しているということになります。 具体的には、投資効果性に対するシステム監査の監査項目、チェックポイントは、次のようなものになります（表5）。 情報化投資対効果の評価を行う体制が業務部門を含めて確立されていること その体制で事前評価から事後評価まで一貫して行うよう定められていること 情報化計画の中で、経営目標を達成するうえで大きな効果が期待できる戦略分野を見極め、情報化投資を計画していること 情報化計画の中のシステム化案件について、必要な投資額を見積もっていること 投資によって期待される効果を評価するための効果評価指標を設定していること システム化計画の中で明確化した投資対効果について、事前評価を行い、その妥当性を確認したうえでシステム化を意思決定していること 運用段階において、システム化計画の中で明確化した効果目標が達成されていることを評価していること 効果目標の実現に問題がある場合、目標実現のための対応を図っていること 表4の流れに沿って情報化投資マネジメントを実行するのは、業務部門および情報化部門の役割です。システム監査人には、情報化投資マネジメントが適切に行われていることを評価することで、情報システムの投資効果性、有効性の向上に寄与することが期待されています。 お話ししてきたように、情報システムの有効性とは、システムが企業活動に貢献しているか、そのシステムを構築・運用するための投資効率は妥当かということです。情報システムの有効性が企業にとって重要であることは、情報システムが企業活動の重要な要素であることを考えれば、当然のことです。 情報システムの有効性が向上すれば、企業活動が効率化・高度化し、顧客や社会に対する企業価値が高まります。ビジネス面から見れば、その結果として、企業の競争優位性が高くなり、顧客増大、売り上げ拡大、利益率向上に貢献します。 情報システムの有効性についてのシステム監査は、先に述べた監査基準の設定や監査手続きの確立の難しさから、普及が遅れている領域です。しかし、情報システムの企業活動の中での位置付けがますます重要になってきている今日、方法論の研究とともにその取り組みが大きな注目を集めるようになってきています。 情報システムの有効性を考えるうえで、「投資効果性」「採算性」という視点が重要である システムの有効性は、利用者の満足度によって測られ、直接話を聞いたり、アンケート調査などによって行われる 情報化投資マネジメントを実行するのは、業務部門および情報化部門の役割 情報システムの投資対効果を考えるうえでは有効性（＝目的、目標に対して妥当な投資、方法で効果を実現しているか）に着目して評価する必要がある。これは「投資効果性」「採算性」と呼ばれ、今日情報システムの有効性を示す重要な視点の1つとなっている。 また情報システムの有効性は、投資対効果のほかにさまざまな視点がある。「目的適合性」「適時性」「利便性」「有用性」「操作性」「機能性」「性能」「拡張性」……などである。情報システムの有効性に対するシステム監査の実際は、経営戦略から情報戦略、情報化計画、システム化計画、それに基づいたシステム構築という基本的な流れがあり、これに従って情報化が進められているかを評価する。システムが有効かどうかは、その利用者たちが満足しているかであり、この人々に話を聞く方法、アンケート調査などによって行われる。 情報化投資マネジメントを実行するのは、業務部門および情報化部門の役割である。システム監査人には、情報化投資マネジメントが適切に行われていることを評価することで、情報システムの投資効果性、有効性の向上に寄与することが期待されている。 この有効性に関するシステム監査は、監査基準の設定や監査手続きの確立の難しさから、普及が遅れている領域だが、情報システムの企業活動の中での位置付けがますます重要になってきている今日、方法論の研究とともにその取り組みが大きな注目を集めるようになってきている。 早稲田大学理工学部出身。システム監査企業台帳登録企業、情報セキュリティ監査企業台帳登録企業 業務改革支援、情報戦略立案、情報化計画策定、情報化投資対効果評価、情報システム監査 公認システム監査人、中小企業診断士、ITコーディネータ、技術士（情報工学）、CISA（公認情報システム監査人）、ISMS主任審査員 日本システム監査人協会、システム監査学会、中小企業診断協会、ITコーディネータ協会、日本技術士会、経営情報学会、情報システムコントロール協会 『システムコンサルタントになる本』（共著、日本能率協会マネジメントセンター）ほか多数 情報マネージャのための「今日のひと言」 - 2007/11/22『クレームはニーズ』 クレームは「できれば受けたくない」「厄介もの」と感じている人が多いようです。ビジネスでは……>>続きはクリック ホワイトペーパー利用者に「Amazonギフト券」を抽選で100名様にプレゼント！――TechTargetジャパン リニューアル・キャンペーン ＠IT情報マネジメント トップ｜IT戦略 トップ｜会議室｜利用規約｜プライバシーポリシー｜サイトマップ |
[ 154] ＠IT情報マネジメント：情報システムの“有効性”と“投資対効果”を監査する
[引用サイト] http://www.atmarkit.co.jp/fbiz/cbuild/serial/audit/04/01.html
