2.7. クローン

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

高可用性 のプランニングは、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.2. クローンの準備

クローンサブシステムのインストール中に使用できるように、証明書を p12 ファイルにエクスポートする必要があります。このコマンドは、クローンサブシステムをインストールまたは設定するのではなく、インストールの準備をします。pki-server SUBSYSTEM-clone-prepare コマンドを使用してサブシステム証明書をエクスポートする方法の例を次に示します。

例2.5 サブシステム証明書のエクスポート

[root@pki1 ~]$ pki-server ca-clone-prepare --i topology-02-CA --pkcs12-file /tmp/caclone.p12 --pkcs12-password SECret.123
-----------------------------------------------------
Added certificate "subsystemCert cert-topology-02-CA"
-----------------------------------------------------
--------------------------------------------------------
Added certificate "caSigningCert cert-topology-02-CA CA"
--------------------------------------------------------
----------------------------------------------------------
Added certificate "ocspSigningCert cert-topology-02-CA CA"
----------------------------------------------------------
-----------------------------------------------------------
Added certificate "auditSigningCert cert-topology-02-CA CA"
-----------------------------------------------------------
エクスポートされた p12 ファイルに証明書が含まれていることを確認できます。次の例では、pki pkcs12-cert-find の出力で 4 つの証明書が返されます。 
[root@pki1 ~]$ pki pkcs12-cert-find --pkcs12-file /tmp/caclone.p12 --pkcs12-password SECret.123
---------------
4 entries found
---------------
Certificate ID: 4649cef11b90c78d126874b91654de98ded54073
Serial Number: 0x4
Nickname: subsystemCert cert-topology-02-CA
Subject DN: CN=Subsystem Certificate,OU=topology-02-CA,O=topology-02_Foobarmaster.org
Issuer DN: CN=CA Signing Certificate,OU=topology-02-CA,O=topology-02_Foobarmaster.org
Trust Flags: u,u,u
Has Key: true

Certificate ID: a304cf107abd79fbda06d887cd279fb02cefe438
Serial Number: 0x1
Nickname: caSigningCert cert-topology-02-CA CA
Subject DN: CN=CA Signing Certificate,OU=topology-02-CA,O=topology-02_Foobarmaster.org
Issuer DN: CN=CA Signing Certificate,OU=topology-02-CA,O=topology-02_Foobarmaster.org
Trust Flags: CTu,Cu,Cu
Has Key: true

Certificate ID: 4a09e057c1edfee40f412551db1959831abe117d
Serial Number: 0x2
Nickname: ocspSigningCert cert-topology-02-CA CA
Subject DN: CN=CA OCSP Signing Certificate,OU=topology-02-CA,O=topology-02_Foobarmaster.org
Issuer DN: CN=CA Signing Certificate,OU=topology-02-CA,O=topology-02_Foobarmaster.org
Trust Flags: u,u,u
Has Key: true

Certificate ID: 3f42f88026267f90f59631d38805cc60ee4c711a
Serial Number: 0x5
Nickname: auditSigningCert cert-topology-02-CA CA
Subject DN: CN=CA Audit Signing Certificate,OU=topology-02-CA,O=topology-02_Foobarmaster.org
Issuer DN: CN=CA Signing Certificate,OU=topology-02-CA,O=topology-02_Foobarmaster.org
Trust Flags: u,u,Pu
Has Key: true
エクスポートされた p12 ファイルを使用して、クローンサブシステムを設定できるようになりました。

2.7.3. 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 設定への変更は、クローンの作成 前 にマスターに加える必要があります (これにより、カスタム変更はクローンプロセスに含まれます)。または、作成後に設定の変更をクローンインスタンスに手動でコピーする必要があります。

2.7.4. KRA のクローン作成

KRA では、1 つの KRA にアーカイブされるすべての鍵が他の KRA の内部データベースに複製されます。これにより、キーがアーカイブされた KRA に関係なく、クローンの KRA で鍵のリカバリーを開始できます。
鍵のリカバリーが処理されると、リカバリーの記録はクローンされたすべての KRA の内部データベースに保存されます。
同期キーリカバリーではクローンでリカバリープロセスが開始できますが、開始された単一の KRA で完了する必要があります。これは、適切な承認数が KRA エージェントから取得されてからのみ復元操作がレプリケートされたデータベースに記録されるためです。それまでは、リカバリーが開始する KRA だけが、リカバリー操作について知っています。
重要
Red Hat Certificate System 9 で非推奨になり、このドキュメントでは説明されていない同期キーリカバリーメカニズムが存在します。Red Hat は、代わりに非同期鍵リカバリーの使用を推奨します。

2.7.5. 他のサブシステムのクローン作成

レプリケートされた TKS には実際の運用上の違いはありません。その 1 つで作成または維持される情報は、その他のサーバーに複製されます。
OCSP の場合、1 つの複製された OCSP のみが CRL 更新を受け取り、公開された CRL はクローンに複製されます。

2.7.6. クローンおよびキーストア

サブシステムのクローンを作成すると、同じ機能を実行するサーバープロセス 2 つが作成されます。別のサブシステムの新規インスタンスが作成され、同じ鍵と証明書を使用してその操作を実行するように設定されます。マスタークローン用の鍵を保存する場所に応じて、キーにアクセスするための方法が非常に異なります。
鍵と証明書が内部ソフトウェアトークンに保存されている場合は、初回の設定時にマスターサブシステムからエクスポートする必要があります。マスターインスタンスを設定する際に、pkispawn 設定ファイルに pki_backup_keys パラメーターおよび pki_backup_password パラメーターを指定して、システムキーと証明書を PKCS #12 ファイルにバックアップできます。詳細は pki_default.cfg(5) の man ページ の BACKUP PARAMETERS セクションを参照してください。
初期設定時に鍵がバックアップされていない場合は、「ソフトウェアデータベースからのサブシステムキーのバックアップ」 に記載されているように、PKCS12Export ユーティリティーを使用して PKCS #12 ファイルに鍵を抽出できます。
次に、PKCS #12 ファイルを clone サブシステムにコピーし、pki_clone_pkcs12_password パラメーターおよび pki_clone_pkcs12_path パラメーターを使用して pkispawn 設定ファイルにその場所とパスワードを定義します。詳細は、pkispawn(8) man ページの Installing a Clone セクションを参照してください。特に、PKCS#12 ファイルが pkiuser ユーザーからアクセスできることを確認し、正しい SELinux ラベルがあることを確認します。
鍵と証明書がハードウェアトークンに保存されている場合は、ハードウェアトークン固有のユーティリティーを使用して鍵と証明書をコピーするか、またはトークンで直接参照する必要があります。
  • SSL/TLS サーバーキーと証明書をクローンインスタンスに対して除いた、必要なすべての鍵と証明書を複製します。これらの証明書のニックネームは同じままにします。さらに、必要なすべてのルート証明書をマスターインスタンスからクローンインスタンス (チェーンやクロスペアの証明書など) にコピーします。
  • トークンがネットワークベースである場合、鍵と証明書は単にトークンで利用できる必要があり、鍵と証明書はコピーする必要はありません。
  • ネットワークベースのハードウェアトークンを使用する場合は、単一障害点を回避するために、ハードウェアトークンで高可用性機能が有効になっていることを確認してください。

2.7.7. LDAP とポートに関する考慮事項

「クローン作成について」で説明したように、クローン作成の動作の一部は、複製されたサブシステム間で情報を複製することです。これにより、サブシステムは同一のデータセットとレコードから機能します。つまり、レプリケートされたサブシステムの LDAP サーバーが通信できる必要があります。
Directory Server インスタンスが異なるホストにある場合は、Directory Server インスタンスが相互に接続できるように、適切なファイアウォールアクセスがあることを確認してください。
注記
クローン作成されたサブシステムとそのマスターは、共通の接尾辞間でデータを複製しつつ、別の LDAP サーバーを使用する必要があります。
サブシステムは、LDAPS ポートを介した SSL/TLS または LDAP ポートを介した標準接続のいずれかを使用して、内部データベースに接続できます。サブシステムが複製されると、複製インスタンスはそのマスターと同じ接続方法 (SSL/TLS または標準) を使用してデータベースに接続します。ただし、クローン作成では、追加のデータベース接続があります。マスターの Directory Server データベースからクローンの Directory Server データベースへの接続です。この接続には、以下の 3 つの接続オプションがあります。
  • マスターが SSL/TLS を使用してデータベースに接続する場合、クローンは SSL/TLS を使用し、マスター/クローンの Directory Server データベースはレプリケーションに SSL/TLS 接続を使用します。
  • マスターがデータベースへの標準接続を使用する場合、クローンは標準接続を使用する必要があり、Directory Server データベースは、暗号化されていない接続を複製に使用 できます。
  • マスターがデータベースへの標準接続を使用する場合、クローンは標準接続を使用する必要があります が、複製用のマスター/クローンの Directory Server データベースに Start TLS を使用するオプションがあります。TLS は、標準ポートでセキュアな接続を開きます。
    注記
    TLS を使用するには、SSL/TLS 接続を受け入れるように Directory Server を設定する必要があります。つまり、クローンを設定する前に、サーバー証明書と CA 証明書を Directory Server にインストールし、SSL/TLS を有効にする必要があります。
マスターが使用する接続メソッド (セキュアまたは標準) はクローンで使用し、クローンを設定する前に Directory Server データベースに対して適切に設定する必要があります。
重要
クローンが安全な接続を介してマスターに接続する場合でも、クローンの設定中は、標準の LDAP ポート (デフォルトでは 389) が開いていて、LDAP サーバーで有効になっている必要があります。
セキュアな環境では、クローンの設定後にマスターの Directory Server インスタンスで標準の LDAP ポートを無効にすることができます。

2.7.8. レプリカ ID 番号

クローン作成は、マスターインスタンスの Directory Server と、クローンインスタンスの Directory Server との間でレプリカ合意を設定することをベースとしています。
レプリケーションとともに関連するサーバーは、同じレプリケーション トポロジー にあります。サブシステムインスタンスのクローンが作成されるたびに、トポロジー全体に追加されます。Directory Server は、レプリカ ID 番号 に基づいてトポロジー内の異なるサーバー間で区別されません。このレプリカ ID は、トポロジー内のすべてのサーバーで一意である必要があります。
要求および証明書に使用されるシリアル番号の範囲 (「CA のクローン作成」) と同様に、すべてのサブシステムには、許可されるレプリカ ID の範囲が割り当てられます。サブシステムのクローン時に、レプリカ ID の 1 つをその範囲から新しいクローンインスタンスに割り当てます。 
dbs.beginReplicaNumber=1
dbs.endReplicaNumber=95
インスタンスが現在の範囲を使い果たし始めると、レプリカ ID の範囲を新しい番号で更新できます。

2.7.9. カスタム設定およびクローン

クローンの作成後、クローン間、またはマスターとクローンの間で 設定 の変更は複製されません。インスタンスの設定は、複製されたデータベースの外部にある CS.cfg ファイルにあります。
たとえば、CA にはマスターとクローンの 2 つがあります。設定に関連付けられる新しい KRA が、マスター CA とともにインストールされている。CA-KRA コネクター情報はマスター CA の CS.cfg ファイルに保存されますが、このコネクター情報はクローン CA 設定に追加されません。キーアーカイブを含む証明書要求がマスター CA に送信される場合は、CA-KRA コネクター情報を使用してキーのアーカイブが KRA に転送されます。要求がクローン CA に送信される場合、KRA は認識されず、キーのアーカイブ要求は許可されません。
マスターサーバーまたはクローンサーバーの設定に加えた変更は、他のクローンインスタンスに複製されません。クローンを作成するには、重要な設定を手動で追加する必要があります。
注記
マスターサーバーの必要なカスタム設定をすべて設定してから、クローンを設定できます。たとえば、すべてのコネクター情報がマスター CA 設定ファイルにあるようにインストールしたり、カスタムプロファイルを作成したり、マスター OCSP レスポンダーのすべての公開ポイントを設定したりします。LDAP プロファイルが Directory Server に保存されている場合は、複製され、サーバー間で同期されることに注意してください。
マスターインスタンスのカスタム設定は、クローン時に クローンのインスタンスに追加されます (ただし、後では機能しません)。