2.7. クローン作成について

高可用性 のプランニングは、1 つ以上のサブシステムのクローンを利用できることで、予定外の停止やその他の問題を削減します。ホストマシンがダウンすると、複製されたサブシステムは要求を処理してサービスを実行し、マスター (元の) サブシステムからシームレスに引き継ぎ、サービスを中断することなく維持できます。
クローン作成されたサブシステムを使用すると、PKI システムのサービスを中断せずに、修復、トラブルシューティング、またはその他の管理タスクのためにシステムをオフラインにできます。
注記
TPS 以外のすべてのサブシステムをクローンできます。
クローン作成は、証明書要求を処理するなど、異なるマシン上のインスタンスを分離することで、PKI にスケーラビリティーを提供する 1 つの方法です。マスターとそのクローンの内部データベースは相互に複製されるため、1 つのサブシステムの証明書要求またはアーカイブされたキーに関する情報は、他のすべてのサブシステムで利用できます。
通常、マスターおよびクローンインスタンスは異なるマシンにインストールされ、それらのマシンは ロードバランサー の内側に配置されます。ロードバランサーは、Certificate System サブシステムに送信された HTTP および HTTPS 要求を受け入れ、それらのリクエストをマスターインスタンスとクローンインスタンスとの間で適切にダイレクトします。一方のマシンに障害が発生した場合、ロードバランサーは、もう一方のマシンがオンラインに戻るまで、まだ実行中のマシンにすべての要求を透過的にリダイレクトします。

図2.5 クローン作成の例

クローン作成の例
Certificate System サブシステムの前にあるロードバランサーは、高可用性システムで実際のフェイルオーバーサポートを提供するものです。ロードバランサーは、Certificate System サブシステムの一部として以下の利点があります。
  • DNS ラウンドロビン。複数のサーバーに負荷を分散するネットワーク輻輳を管理する機能です。
  • スティッキー SSL/TLS。これにより、ユーザーがシステムに戻して、以前使用された同じホストをルーティングできるようになります。
通常、システムのクローンを作成すると、設定サーブレットは内部 LDAP データベース間でレプリカ合意を設定します。ただし、一部のユーザーは、独自のレプリカ合意を確立して管理する場合があります。PKI インスタンスに [Tomcat] セクションを追加し、そのセクションに次の 2 つの name=value ペアを追加することにより、pkispawn 実行ファイルが変更され、これを許可するようになりました。
[Tomcat]
pki_clone_setup_replication=False
pki_clone_reindex_data=False
重要
このようなインストールを指定する場合は、pkispawn を起動する 前に データを複製する必要があります。

2.7.1. CA のクローン作成

クローン作成されたインスタンスはマスターと全く同じ秘密鍵を持つため、それらの証明書は同じになります。CA の場合、つまり、CA 署名証明書が元のマスター CA およびそのクローン作成された CA と同一であることを意味します。クライアントの観点からは、これは単一の CA に似ています。
クローンとマスターの両方のすべての CA は、証明書を発行し、失効要求を処理できます。
複製された CA を管理する主な問題は、発行する証明書にシリアル番号を割り当てる方法です。複製されたCA が異なれば、異なるレートのシリアル番号を使用してトラフィックのレベルが異なる可能性があり、2 つの複製された CA が同じシリアル番号の証明書を発行しないことが不可欠です。これらのシリアル番号範囲は、各 CA の範囲を定義する共有の複製エントリーと、1 つの CA 範囲が少なくなったときに再割り当てする次の使用可能な範囲を使用して、動的に割り当ておよび管理されます。
クローン CA を使用するシリアル番号の範囲は fluid です。すべての複製された CA は、次の利用可能な範囲を定義する共通の設定エントリーを共有します。1 つの CA が利用可能な数未満の実行を開始すると、この設定エントリーをチェックし、次の範囲を要求します。エントリーは自動的に更新されます。これにより、次の CA が新規範囲を取得します。
範囲は begin*Number 属性および end*Number 属性で定義され、個別の範囲が要求および証明書のシリアル番号に対して定義されます。以下に例を示します。
 dbs.beginRequestNumber=1
 dbs.beginSerialNumber=1
 dbs.enableSerialManagement=true
 dbs.endRequestNumber=9980000
 dbs.endSerialNumber=ffe0000
 dbs.replicaCloneTransferNumber=5
CRL を生成、キャッシュ、公開できるのは 1 つの複製 CA のみになります。これは CRL CA です。複製された他の CA に送信された CRL 要求は、すぐに CRL CA にリダイレクトされます。複製された他の CA は、以前 CRL CA によって生成された CRL を取り消し、表示、インポート、およびダウンロードできますが、新しい CRL を生成すると、同期の問題が発生する可能性があります。CRL 生成を別の複製された CA に移動する方法は、「CA クローンおよびマスターの変換」を参照してください。
マスター CA は、内部データベースへのレプリケーションの変更を監視することで、クローンされた CA 間の関係と情報共有も管理します。
注記
セキュリティードメインマスターである CA がクローンされた場合、そのクローン作成された CA はセキュリティードメインマスターになります。この場合、元の CA とクローンの両方が同じセキュリティードメイン設定を共有します。
重要
「カスタム設定およびクローン」で説明されているように、LDAP データベースのデータはマスターとクローン間で複製されますが、異なるインスタンス用の 設定ファイル は複製されません。つまり、クローンの作成 に変更が発生すると、KRA 接続の追加やカスタムプロファイルの作成など、CS.cfg ファイルに影響する変更が、クローンの設定にコピーされません。
CA 設定への変更は、クローンの作成 にマスターに加える必要があります (これにより、カスタム変更はクローンプロセスに含まれます)。または、作成後に設定の変更をクローンインスタンスに手動でコピーする必要があります。