PKIとは何ですか？

PKIは、デジタル証明書の技術的基盤である公開鍵基盤（Public Key Infrastructure）の頭字語です。 デジタル証明書は、運転免許証やパスポートと同様の目的を果たすもの、つまり身元を証明し、一定の手続きを容認させる身分証明書です。 所有者はデジタル証明書を使用して暗号化、署名、認証を実行できます。 このようにPKIは、データの暗号化、ドキュメントのデジタル署名、証明書を使用した自分自身の認証を可能にする技術です。

企業が効果的な公開鍵基盤を実装するには、多くの要件があります。 何より、ユーザーがアプリケーションの暗号化とデジタル署名を利用できなければ、PKIに価値はありません。 したがってPKIで最も重要な制約は透過性です。 ユーザーから見てこの透過性という用語は、PKIが鍵と証明書を管理する仕組みを理解していなくても、暗号化とデジタル署名のサービスを活用できることを指します。 効果的なPKIは透過的です。 企業の場合はユーザーの透過性に加え、次のアイテムをPKIに実装しないと、必要な鍵と証明書管理のサービスを提供できません。

• 公開鍵証明書
• 証明書リポジトリ
• 証明書の失効
• 鍵のバックアップと復元
• デジタル署名のNon-Repudiationのサポート
• 鍵ペアと証明書の自動更新
• 鍵履歴の管理
• 相互認証のサポート
• 安全性、一貫性、信頼性を確保しながら以上のすべてと連携するクライアント側ソフトウェア

注： 「クライアント側」という用語は、アプリケーションクライアントとアプリケーションサーバーを指しています。 PKI要件はアプリケーションのクライアントとサーバーの両方で共通しており、両方とも基盤サービスの「クライアント」です。

使いやすく透過的で自動的に動作するPKIを装備するには、併せてこれらの要件をすべて満たす必要があります。

ユーザーが通信相手の「安全性」、つまり通信相手のIDと鍵の有効性、そして信頼性を保証しない限り、公開鍵暗号化は効力を発揮しません。 そして保証するには、PKIのユーザー全員に登録済みのIDが必要です。

このIDは標準のX.509デジタル公開鍵証明書形式で保存されています。 CA（認証局）とは、ユーザー名を公開鍵と安全に結び付けるデジタル証明書の作成に関わる人物、プロセス、ツールを指します。 証明書の作成にあたり、CAがPKIの信頼基盤（信頼された機関）として機能します。 ユーザーがCAを信頼し、証明書の発行と管理に関するCAのビジネスポリシーを信頼する限り、ユーザーはCAによって発行された証明書を信頼できます。 これを「第三者機関による信頼」といいます。

CAは、次のような情報（追加項目を含む）からなる一連のデータにデジタル署名を施す形で、ユーザーの証明書を作成します。

1. 識別名（DN）形式のユーザー名。 DNではユーザー名、個々のユーザーの識別に必要な追加属性をすべて指定します（たとえばDNにユーザーの従業員番号を含めることができます）。
2. ユーザーの公開鍵。 公開鍵は、ユーザーが受け取るデータを送信側ユーザーがあらかじめ暗号化したり、ユーザーのデジタル署名を提出先が検証したりするために必要です。
3. 証明書の有効期間（開始日と終了日）。
4. 公開鍵を使用するとき（データの暗号化やデジタル署名の検証）の具体的な操作。

証明書にCAの署名があれば、証明書の内容が改ざんされた場合も、簡単に検出できます。 CAが証明書に施した署名は、薬瓶の改ざん防止シールと同じ働きをします。万一証明書の内容が改ざんされれば、そのことが簡単にわかります。 逆にCAの署名を検証できる限り、その証明書はデータ完全性を保持しています。 CAの署名さえ検証すれば証明書の完全性を判断できるため、証明書は本質的に安全であり、完全にパブリックな方法（誰でもアクセスできるディレクトリシステムを使用するなど）でも配布できます。

証明書から公開鍵を取得するユーザーには、公開鍵が有効であることが保証されます。 つまりユーザーは、証明書と証明書に関連付けられた公開鍵が、識別名が指定するエンティティのものだと信頼できます。 ユーザーは公開鍵が定義された有効期間内であることも信頼します。 公開鍵がCAの認定した方法で安全に使用できることも、ユーザーに対し保証されます。

PKIはIT戦略の根幹をなす重要部分です。 PKIが重要なのは、証明書ベースの技術を使うことで、組織が個人間、システム間、装置間の署名、暗号化、IDにおける信頼を成り立たせることができるからです。

進化するビジネスモデルが電子トランザクションやデジタルドキュメントに依存するようになり、企業ネットワークに接続されるインターネット対応デバイスが増えるにつれ、公開鍵インフラストラクチャの役割は、安全な電子メール、物理アクセス用のスマートカード、または暗号化されたウェブトラフィックなどの分離されたシステムに限定されなくなりました。 今日のPKIは、複雑なエコシステム全体で多数のアプリケーション、ユーザー、およびデバイスをサポートすることが期待されています。 また、政府および業界のデータセキュリティ規制が厳しくなるにつれ、主流のオペレーティングシステムとビジネスアプリケーションは、信頼を保証するために組織のPKIにこれまで以上に依存するようになっています。

認証局またはルート秘密鍵の盗難とは

認証局（CA）またはルート秘密鍵の盗難により、攻撃者は、Stuxnet攻撃で行われたように、組織の公開鍵インフラストラクチャ（PKI）を乗っ取り、偽の証明書を発行することができます。 このような侵害があると、以前に発行された証明書の一部またはすべてが取り消され、再発行される可能性があります。 盗まれたルート秘密鍵などのルート侵害は、PKIの信頼を破壊し、CAインフラストラクチャを発行する新しいルートおよび子会社を再確立するように簡単に促すことができます。 これは、企業のコーポレートアイデンティティを損なうことに加えて、非常に高額になる可能性があります。

ルートから発行CAまでのインフラストラクチャ全体にわたる組織の秘密鍵の整合性は、そのPKIのコア信頼基盤を提供するため、保護する必要があります。 これらの重要なキーを保護するための認識されているベストプラクティスは、最高のセキュリティおよび保証基準を満たす改ざん防止デバイスであるFIPS 140-2レベル3認定ハードウェア・セキュリティ・モジュール（HSM）を使用することです。

PKIとSSLは別種の技術であり、PKIは非公開の信頼、SSLは公開の信頼を確立するという違いがあるものの、どちらもCA（Certificate Authority）が発行した証明書に基づいて「信頼」を確立する証明書ベースのソリューションです。

PKIはハードウェア、ソフトウェア、ポリシーなどで構成されるフレームワーク全体を指します。 PKIには、信頼を確立するためにデジタル証明書を発行するCAも含まれています。 CAは通常、組織に必要なセキュリティと保証のレベルに応じたポリシーと手順に従って内部で管理されます。

SSLはPKIの主なユースケースの1つです。 SSLには証明書を発行するCAも含まれますが、そのCAへの公的な信頼をブラウザが認識できなくてはなりません。 PKIのユースケースは多岐にわたりますが、SSLはオンラインバンキングやeコマーストランザクションなどのオンライン通信で転送される機密データを保護する目的で使用されています。

以下の例からわかるとおり、PKIの主なユースケースは、デジタル証明書が一般的に使用されるアプリケーションと一致します。

従来のユースケース

次のビジネスクリティカルなアプリケーションを見ると、PKIが中核的ITの戦略の根幹をなすことが、はっきりとわかります。

• 一般向けのWebサイトやサービスのSSL証明書
• プライベートネットワークとVPN（仮想プライベートネットワーク）
• パブリッククラウドを利用したアプリケーションおよびサービス
• プライベート クラウド ベースのアプリケーション
• Eメールのセキュリティ
• 企業向けユーザー認証
• デバイス認証
• プライベート クラウド ベースの認証
• ドキュメントやメッセージへの署名
• コードサイニング

（下図の詳細を参照してください）。

新たなユースケース

DevOps関連のユースケースでも、以下のようなPKI採用が増え、再びPKIが重視されるようになっています。

• クラウドベースサービス
• 消費者向けモバイル
• IoT（モノのインターネット）
• 消費者志向のモバイルアプリケーション
• 持ち込みデバイス（BYOD）ポリシーと内部のモバイルデバイス管理
• eコマース

（下図の詳細を参照してください）。

また一部の専門家の予測によれば、技術と人工知能のさらなる進歩に伴い、今後はさらにユースケースが増えていきます。

秘密鍵と公開鍵の違いは、用途が暗号化か復号化かです。

公開鍵は暗号化用で、ほぼ受信者にしか読めない形に情報を変換するために使用されます。 受信者は秘密鍵を保持し、秘密鍵を使用することで、受信データを復号化できます。

また公開鍵は、機密性を保持して情報を送信する必要があるユーザー全般に提供されます。 たとえば共有ディレクトリに置いた情報については、社内の同僚が公開鍵を入手できるかもしれません。 逆に秘密鍵は指定された受信者専用であるため、その暗号化情報はほかの誰も正常には復号化できません。

つまり公開鍵と秘密鍵を組み合わせると、情報、データ、通信が暗号化されてから安全に送信され、適切な受信者の手で復号化されるよう徹底できます。

ユーザーが復号鍵を紛失したときに備え、企業は暗号化データを復元できる体制を整えておかなくてはなりません。 つまりユーザーの所属企業に、復号鍵をバックアップしたり復元したりするシステムが必要です。

企業にとって鍵のバックアップと復元が非常に重要となる理由は、次の2つです。

1. ユーザーはパスワードを忘れることがあります。 ユーザーが復号鍵へのアクセスに必要なパスワードを忘れると、その企業は該当するデータを失い、大変な事態になるかもしれません。 鍵を安全に回復する能力がなければ、貴重な情報が永久に失われます。 一方で暗号化データをいつでも（パスワードを忘れた場合も）回復できることを知らないユーザーは、最重要機密を失う可能性を恐れ、最も保護すべき最重要機密を暗号化しなくなるでしょう。
2. ユーザーの復号鍵が保存されているデバイスが紛失したり、物理的に壊れたり、データが破損したりするかもしれません。 たとえばユーザーの復号鍵が磁気カードに保存されているとき、カードの磁場が破損する場合があります。 この場合も、所定の復号鍵が永久に失われると、悲惨な結果になる可能性があります。 所定の復号鍵がバックアップされていない限り、ユーザーは暗号化データを回復できません。

鍵のバックアップと鍵のエスクローの違い

鍵のバックアップとリカバリに関する商用要件は、メディアで広く議論されている鍵のエスクローに関する法執行要件から完全に分離できます。

• キーエスクローとは、暗号化情報へのアクセスに必要な復号鍵を第三者（連邦政府機関など）が取得できる枠組みを指します。 キーエスクローの主旨は、法の執行を支えることにあります。公益（国家安全保障など）と個人の自由やプライバシーとの微妙な境界線をめぐり、キーエスクローは議論が白熱しています。
• 鍵のバックアップと復元に関する要件の主旨は、法執行機関の要件とは無関係に存在する基本的な商業上のニーズにあります。

どの鍵にバックアップが必要ですか？

バックアップが必要な鍵は、ユーザーの復号鍵のみです。 信頼できる機関（CAなど）がユーザーの復号鍵を安全にバックアップしている限り、ユーザーのデータはいつでも回復でき、セキュリティが損なわれることもありません。 その一方で署名鍵には、復号鍵とは異なる要件があります。 現に次のセクションで説明するとおり、署名鍵をバックアップすると、PKIの基本的な要件が満たされなくなります。

否認（Repudiation）は個人がトランザクションへの関与を拒否したときに発生します。 たとえば誰かがクレジットカードが盗まれたと主張すると、盗難報告後に随時そのカードで発生する取引の責任を否認したと見なされます。

Non-Repudiationとは、個人がトランザクションへの関与を否認できない状態を指します。 紙ベースの取引では、紙に書かれた個人の署名が、その個人を取引（クレジットカードの請求、ビジネス契約など）に拘束する法的根拠になります。 署名があることで、取引を否認できなくなります。

電子商取引では、紙ベースの署名の代わりにデジタル署名が使用されます。 従来の紙ベースの署名ではeコマースのメリットが失われるため、あらゆるeコマースでデジタル署名が必須です。

署名用秘密鍵

Non-Repudiationの最も基本的な要件は、デジタル署名の作成に使用する鍵（署名鍵）が生成され、その鍵をユーザーが自分以外には制御できない方法で安全に保管することです。 署名鍵は絶対にバックアップしてはなりません。 暗号鍵ペアとは異なり、ユーザーがパスワードを忘れたり、署名鍵が紛失したり、物理的に壊れたり、署名鍵のデータが破損したりするとしても、技術上や事業上は以前の署名鍵ペアのバックアップや復元が一切必要ありません。 しかもユーザーが新しい署名鍵ペアを生成し、以後は新しい方の署名鍵ペアを使用してもかまいません。

2つの鍵ペアの必要性

鍵のバックアップとリカバリと否認防止を同時にサポートすることは困難です。 鍵のバックアップや復元をサポートするには、復号鍵を安全にバックアップする必要があります。 ところがNon-Repudiationをサポートするには、デジタル署名用の鍵をバックアップせず、常にユーザー本人の単独の管理下に置く必要があります。

両方の要件を満たすには、PKIでユーザーごとに2組の鍵ペアをサポートする必要があります。 ユーザーは常に、暗号化と復号化に使う最新の鍵ペア1組と、デジタル署名と署名検証に使う2組目の鍵ペアを保持する必要があります。 時間の経過とともに、ユーザーは適切な管理を要する鍵ペアを多数保管することになります。

暗号鍵のペアは、いつまでも同じペアを使用せず、時間の経過とともに更新していく必要があります。 結果的に、すべての組織で次の2つの重要事項を検討する必要があります。

1. ユーザの鍵ペアの更新 - 鍵のペアを更新するプロセスには、ユーザにとってわかりやすい透過性が必要です。 ここで言う透過性とは、ユーザーにとって、どの鍵を更新するべきかを理解しなくても、鍵の無効化による「サービス拒否」が発生しない状態です。 透過性を確保し、サービス拒否を防ぐには、ユーザーの鍵ペアが有効期限内に自動更新されなくてはなりません。
2. 必要に応じて以前の鍵ペアの履歴を維持 - 暗号鍵のペアを更新するときは、以前の復号鍵の履歴が維持されている必要があります。 ユーザーはこの「鍵履歴」に沿って以前の復号鍵にアクセスし、データを復号化できます（データがユーザーの暗号鍵で暗号化されている場合、対応する復号鍵（ペアになっている鍵）のみを復号化に使用できます）。透過性を確保するには、クライアント側のソフトウェアでユーザーの復号鍵履歴を自動的に管理する必要があります。

また鍵履歴は、鍵のバックアップと復元のシステムによって安全に管理する必要があります。 そうすれば、最初にデータ暗号化に使用された公開暗号鍵が何であっても（さらにはいつ暗号化されたデータであっても）、暗号化されたデータを安全に復元できます。

署名鍵のペアが更新されるときは、以前の署名鍵が安全に破棄されなくてはなりません。 そうすれば、他人が署名鍵にアクセスできなくなります。また以前の署名鍵を保持する必要がないため、破棄しても問題ありません。

前述のとおり、CAは信頼できる第三者機関として機能し、ユーザーに証明書を発行します。 企業も、アプリケーションで使用できるようにこの証明書を配布する必要があります。 証明書リポジトリは、アプリケーションがユーザーに代わってこの証明書を取得できるように、証明書を格納します。

「リポジトリ」という用語は、証明書の配布を可能にするネットワークサービスを指します。 証明書リポジトリに最も適しているのは、LDAP（Lightweight Directory Access Protocol）に準拠したディレクトリシステムが提供する技術だというのが、過去数年間のIT業界の共通認識です。 LDAPはディレクトリシステムに対するアクセスの標準プロトコルを規定します。

この共通認識には、いくつかの要因が関わっています。

• ディレクトリに証明書を保存し、アプリケーションがユーザーに代わって証明書を取得する仕組みで、ほとんどのビジネスアプリケーションに必要な透過性が備わります
• LDAPに対応するディレクトリ技術の多くは、拡張によって以下をサポートできます。
  • 非常に多くのエントリをサポートする
  • 情報の格納方法と検索方法により、検索要求に効率的に対応する
  • 最も大きく分散化された組織でも要件を満たせるように、ネットワーク全体にわたって分散化する

また証明書の配布をサポートするディレクトリは、他の組織情報も格納できます。 次のセクションで説明するように、PKIがディレクトリを使用して証明書失効情報を配布することもあります。

アプリケーション ソフトウェアは、証明書のCA署名を検証する（前述の「証明書、認証局にはどのような役割がありますか？」項目を参照）だけでなく、使用時にも証明書の信頼性が失われていないことを確認する必要があります。 信頼できなくなった証明書はCAに従い、失効させなくてはなりません。 有効期間が終了していなくても、証明書の失効が必要になる理由はたくさんあります。 たとえば、証明書の公開鍵に対応する秘密鍵（署名鍵または復号鍵のいずれか）が侵害を受けるケースがあります。 あるいは組織のセキュリティポリシーで、組織を離れる従業員の証明書を取り消すよう義務付けられているケースもあります。

このような場合、以後は該当する証明書の使用が安全とは見なされなくなった旨をシステム内のユーザーに、通知する必要があります。 証明書を使用する前に、失効ステータスの確認が必要です。 以上により、PKI内には拡張可能な証明書失効の仕組みが必須です。 システム内の各証明書のステータス情報を安全に公開する機能が、CAに必要です。 アプリケーションソフトウェアは、証明書を使用する前に、ユーザーに代わって証明書の失効情報を検証する必要があります。

証明書の失効情報を公開すること、常に使用することが同時に実現して初めて、証明書失効の仕組みは完成します。 証明書の失効情報を配布する最も一般的な方法は、CAが安全な証明書失効リスト（CRL）を作成し、ディレクトリシステムに公開する方法です。 CRLでは、失効した証明書がすべて、それぞれ固有のシリアル番号で指定されます。

証明書を使用する前に、クライアント側アプリケーションが適切なCRLをチェックし、証明書を引き続き信頼できるかどうか判断する必要があります。 ユーザーに代わりクライアント側アプリケーションは、失効済み証明書を常に透過的にチェックする必要があります。

相互認証により認証局ドメイン間で第三者間の信頼関係が広がります。 たとえば互いに独自のCAを持つ取引パートナー2社が、相手方CAで発行された証明書を検証する必要が生じる場合があります。 あるいは大規模な分散型組織で、各地に複数のCAが必要になる場合があります。 相互認証により、異なるCAドメイン間で信頼できる電子関係を確立し、維持することができます。

相互認証という用語が指す操作は次の2つです。

1. 2つのCA間で信頼関係を確立すること（実行頻度低）です。 2つのCAが相互認証を実行する場合は、安全な方法を使い、両CA間で検証鍵が交換されます。 ここで交換される鍵は、証明書内のCAによる署名を検証するために使用される鍵です。 この操作を完了するため、各CAは「相互証明書」という証明書で相手方CAの検証鍵に署名します。
2. 相互認証済みCAが署名したユーザー証明書の信頼性の検証（実行頻度高）。 このとおりです。 クライアント側のソフトウェアが実行する操作はよく「信頼の鎖をつたい歩く」と表現されます。 「鎖」とは、検証者のCA鍵から他ユーザーの証明書を検証するために必要なCA鍵まで「つたい歩く」（つまりトレースする）相互証明書検証のリストを指します。 相互証明書の鎖をつたい歩くときは、各相互証明書をチェックし、信頼性が維持されていることを確認する必要があります。 ユーザー証明書は失効可能にしておく必要があるため、相互証明書が欠かせません。 この要件は、相互認証に関する議論では見過ごされがちです。

PKIの要件については、企業がクライアント側ソフトウェアの要件を無視することも少なくありません （たとえばPKIに関する議論では、多くの人がCAコンポーネントにのみ注目します）。 ところが結局のところPKIの価値は、ユーザーが暗号化とデジタル署名を使用できるかどうか次第です。 このためPKI内には、デスクトップの多様なアプリケーション（電子メール、Webブラウジング、電子フォーム、ファイルやフォルダーの暗号化など）で一貫して透過的に動作するクライアント側ソフトウェアが必須です。

使いやすく一貫性のあるPKIをクライアント側ソフトウェアに実装すると、PKIの運用コストを削減できます。 またPKIの全要素をサポートするには、クライアント側ソフトウェアを技術的に有効にしておく必要があります。 次のリストは、ビジネスユーザーが使いやすく透過的な（つまり容認できる）PKIを確実に受け取るために、クライアント側ソフトウェアが満たすべき要件をまとめたものです。

• 公開鍵証明書 第三者の信頼性を保証するには、すべてのPKI対応アプリケーションが、信頼できる一貫した方法で証明書を使用している必要があります。 クライアント側ソフトウェアは、CAによる証明書への署名を検証し、証明書が有効期間内にあることを確認する必要があります。
• 鍵のバックアップと復元 ユーザーをデータ損失から確実に保護するには、PKIで復号鍵のバックアップと復元に必要なシステムをサポートする必要があります。 管理コストを考えると、各アプリケーションが独自の鍵のバックアップと復元を提供する方法は受け入れられません。 むしろすべてのPKI対応クライアント アプリケーションが、1つの鍵のバックアップと復元のシステムで連携するべきです。 鍵のバックアップと復元のシステムとクライアント側ソフトウェアの安全な連携が必須であり、すべてのPKI対応アプリケーションで一貫した連携が必要です。
• 否認防止のサポート Non-Repudiationの基本的なサポートを提供するには、クライアント側ソフトウェアがデジタル署名用の鍵ペアを生成する必要があります。 しかも署名鍵のバックアップは、クライアント側ソフトウェアでは行わず、常にユーザーの制御下に置かなくてはなりません。 このようなサポートをすべてのPKI対応アプリケーションで一貫させる必要があります。
• 鍵ペアの自動更新 透過性を持たせるには、クライアント側アプリケーションがユーザーの鍵ペアの更新を自動的に開始する必要があります。 実施するときは、組織のセキュリティポリシーに必ず準拠してください。 鍵ペアの更新が必要なタイミングをユーザーが把握していなければならないやり方は、効率が悪すぎます。 すべてのPKI対応アプリケーションでこの要件を満たすには、クライアント側ソフトウェアが一貫性と透過性を確保する形で鍵ペア更新する必要があります。
• 鍵履歴の管理 ユーザーが（暗号化された時期に関係なく）すべての暗号化データに簡単にアクセスできるようにするには、PKI対応アプリケーションにユーザーの鍵履歴へのアクセス権を持たせる必要があります。 またクライアント側ソフトウェアが、ユーザーの鍵の履歴を安全に回復できる必要があります。
• 拡張可能な証明書リポジトリ 証明書の配布コストを最小限に抑えるには、すべてのPKI対応アプリケーションで共通の拡張可能な証明書リポジトリを使用する必要があります。

新しいアプリケーションのサポート

多くの場合、アプリケーションでPKIを使用するのは困難です。 Ponemon Instituteの『2019 PKI and IoT Trends Report』（2019年度PKIおよびIoTトレンド報告書）によると、アプリケーションでPKIを使用するにあたり、多くの組織が常に直面する2大課題は、既存のPKIが新規のアプリケーションをサポートしない点とレガシーアプリケーションを変更できない点です。

（下図の詳細を参照してください）。

明確な所有権の欠如

同じ調査結果から、PKI環境での主要課題は今も、PKI機能の責任者が不明確な点であるともわかっています。 ともあれ今日のPKI環境では、特に次の点を考慮し、適切に管理しなくてはなりません。

• 分散化された基盤内で多くの証明書が多くの人、場所、物に発行される
• セキュリティを確保するべき「モノ」が従来より増え、短期間で失効する証明書への対処が必要
• 重要なビジネスアプリケーションのセキュリティが証明書で保証されており、その状態が損なわれるとコストがかかり、原因究明が難しい場合もある

特定部門内のPKI管理を一元化し、1つのインターフェイスで証明書の監視と報告をすべて行えるソフトウェアツールを提供することで、基盤内の多様な証明書を正確にわかりやすく可視化できます。

規格と規制にはいくつも種類があり、特に地域や行政単位が異なると規格や規制も異なることがあります。とは言えPKI展開時に最も重要なセキュリティ証明書は次の2つです。

• Common Criteria EALレベル4以上
• FIPS 140-2 レベル 3