第5章 Certificate System の計画

各 Red Hat Certificate System サブシステムは同じサーバーマシンにインストールするか、別のサーバーにインストールするか、組織全体で複数のインスタンスをインストールすることができます。サブシステムをインストールする前に、デプロイメントを計画することが重要です。どのような種類の PKI サービスが必要ですか。ネットワーク要件Certificate System にアクセスするために必要な人、そのロール、および物理的な場所は何ですか。発行する証明書の種類と、それらの制約またはルールを設定する必要があるか。
本章では、Certificate System のデプロイメントプランニングに関する基本的な質問を説明します。これらのデシジョンの多くは相互関連です。たとえば、スマートカードを使用して TPS サブシステムおよび TKS サブシステムをインストールするかどうかを決定するかどうかを決定するなど、別の選択肢に影響します。

5.1. 必要なサブシステムの決定

Certificate System サブシステムは、証明書管理のさまざまな側面に対応しています。インストールするサブシステムのプランニングは、デプロイメントが必要な PKI 操作を定義する方法の 1 つです。
ソフトウェアや設備などの証明書は、定義されたステージでライフサイクルを持ちます。最も基本的な手順は以下のとおりです。
  • 要求および発行されます。
  • これは有効です。
  • 期限切れになります。
ただし、このシンプルなシナリオでは、証明書に関する多くの共通問題について説明しません。
  • 証明書の有効期限が切れる前に従業員が退職するかどうか
  • CA 署名証明書の有効期限が切れると、その証明書を使用して発行および署名されたすべての証明書も有効期限が切れます。これにより、CA 署名証明書が更新され、発行された証明書が有効に保つか、または再発行されますか ?
  • 従業員がスマートカードを失ったか、またはスマートカードに残るかどうか。元の証明書キーを使用して代替証明書が発行されますか。他の証明書は一時停止または取り消されるか。一時的な証明書は許可されますか。
  • 証明書の有効期限が切れると、新しい証明書を発行するか、元の証明書が更新されますか ?
これにより、証明書の管理に関する他の 3 つの考慮事項 (失効、更新、および代替) を紹介します。
他の考慮事項は、認証局への負荷です。発行や更新のリクエストはたくさんありますか。証明書が有効かどうかの検証を試みるクライアントから大量のトラフィックがありますか。ID を認証するための証明書を要求する人はどのようになっていますか。また、そのプロセスによって発行プロセスが遅くなりますか。

5.1.1. 単一証明書マネージャーの使用

Certificate System PKI の中核は、Certificate Manager (認証局) です。CA は証明書要求を受け取り、すべての証明書を発行します。

図5.1 CA のみの Certificate System

CA のみの Certificate System
要求および発行のための基本処理はすべて、Certificate Manager が処理でき、これは唯一の必須サブシステムです。組織の要求に応じて、単一または多数の Certificate Manager をさまざまな関係で配置することができます。
証明書の発行に加えて、Certificate Manager は証明書を取り消すこともできます。管理者にとっての 1 つの質問は、証明書が紛失、侵害された場合、または証明書が発行された人や機器が会社をいなくなった場合に、証明書をどのように処理するかです。証明書要求を失効すると、失効日前に証明書を無効化し、失効した証明書の一覧がコンパイルされ、発行 CA によって公開され、クライアントが証明書のステータスを検証できるようになります。

5.1.2. 紛失したキーの計画: キーのアーカイブと回復

CA が実行できない 1 つの操作はキーのアーカイブとリカバリーです。非常に現実的なシナリオは、ユーザーが秘密鍵を紛失することです。たとえば、鍵がブラウザーデータベースから削除されたり、スマートカードが家に残されたりする可能性があります。多くの一般的なビジネスオペレーションでは、暗号化された電子メールなどの暗号化されたデータが使用され、そのデータのロックを解除するキーを失うと、データ自体が失われます。会社のポリシーによっては、交換用の証明書を再生成または再インポートするためにキーをリカバリーする方法が必要になる可能性があり、どちらの操作にも秘密キーが必要です。
これには、キーを特別にアーカイブおよび取得するサブシステムである KRA が必要です。

図5.2 CA および KRA

CA および KRA
キーリカバリー機関は暗号鍵 (キーアーカイブ) を保存し、CA が証明書 (キーのリカバリー) を再発行できるようにこれらのキーを取得できます。KRA は、通常の証明書に対して実行される場合でも、スマートカードを登録する場合でも、Certificate Systemによって生成された証明書のキーを格納できます。
キーのアーカイブおよびリカバリーのプロセスは、「キーのアーカイブ、リカバリー、およびローテーション」 で詳細に説明されています。
注記
KRA は、秘密鍵のアーカイブおよび復元を目的としています。したがって、エンドユーザーは、公開鍵と秘密鍵のペアを格納するために、デュアルキー生成をサポートするブラウザーを使用する必要があります。

5.1.3. 証明書要求の処理の分散

サブシステムを連携させる方法のもう 1 つが負荷分散です。サイトのトラフィックが多い場合は、相互のクローンとして、またはフラット階層 (各 CA が独立している場合) またはツリー階層 (一部の CA が他の CA に従属している場合) として、多数の CA を簡単にインストールできます。詳細は、「認証局階層の定義」 を参照してください。

5.1.4. クライアント OCSP 要求の分散

証明書が有効期間内にありますが無効にする必要がある場合は、取り消すことができます。Certificate Manager は、取り消された証明書の一覧を公開することができます。これにより、クライアントが証明書が有効であることを確認する必要がある場合は、一覧を確認できます。これらの要求は、オンライン証明書ステータスプロトコル要求 で、特定の要求と応答の形式を持ちます。Certificate Manager には、OCSP レスポンダーが組み込まれており、OCSP 要求を自分で検証できます。
ただし、証明書要求トラフィックと同様に、サイトには、証明書のステータスを確認するためのクライアントの要求が多数ある可能性があります。Example Corp. には大規模な Web ストアがあり、各顧客のブラウザーは SSL/TLS 証明書の有効性を検証しようとします。ここでも、CA は証明書の発行数を処理することができますが、要求トラフィックが高いとパフォーマンスに影響します。この場合、Example Corp. は外部の OCSP Manager サブシステムを使用して証明書のステータスを確認し、Certificate Manager は更新された CRL を頻繁に公開するだけで済みます。

図5.3 CA および OCSP

CA および OCSP

5.1.5. スマートカードの使用

スマートカードは、キーと証明書のデータを格納するために物理的な媒体を使用するため、通常、直接の登録と承認のプロセスが必要です。つまり、複数のエージェントが TPS にアクセスでき、多くの場合は、異なるオフィスまたは地理的な場所にある複数の TPS サブシステムが必要になります。
トークン管理システムは非常にスケーラブルです。複数の TPS は、単一の CA、TKS、または KRA インスタンスと連携するように設定できますが、複数の Enterprise Security Clients は 1 つの TPS と通信できます。追加のクライアントがインストールされると、TPS を再設定せずに TPS インスタンスを参照できます。同様に、TPS が追加されるため、これらのサブシステムを再設定せずに、同じ CA、TKS、および KRA インスタンスを参照することができます。
インストール後に、TPS 設定を編集して、フェイルオーバーのサポートに追加の CA インスタンス、KRA インスタンス、および TKS インスタンスを使用できます。そのため、プライマリーサブシステムが利用できない場合、TPS はトークンサービスを中断せずに次に利用可能なシステムに切り替えます。