CA 階層の構造の計画

ベストプラクティスとして、組織の構造に合わせた認証局の階層構造を計画してください。 通常、以下の一般的なCA構造のいずれかを実装することができます。

2 つのレベル: ルート CA と従属 CA

このオプションは、ワークロードが最も単純な CA 構造を必要とする場合に使用します。 このシナリオでは、単一のトラステッド・ルート CA を作成します。 次に、中間 CA などの従属 CA を作成して、アプリおよびサービスにリーフ証明書を発行します。

3つの階層：ルートCAと2つの下位認証局

このオプションは、ワークロードでルート CA 操作と下位 CA 操作の間に追加の層が必要な場合に使用します。 このシナリオでは、中間の下位CAは、アプリケーションにリーフ証明書を発行する下位認証局に署名するためだけに使用されます。

CA 階層の深さの設定

Secrets Manager で認証局を作成する場合、最大パス長パラメーターを設定して、その認証局チェーンに存在できる CA 証明書の数を決定できます。 この値は、CA の認証パスに存在できる CA 証明書の数を強制します。

通常、認証パス内で作成できる下位認証局の数を制限しないルートCAを設定することができます。 ただし、下位認証局の最大パス長を定義することは、認証局の設定ミスを防ぐための重要なセキュリティ対策となります。 階層内の従属 CA の配置に応じて、最大パス長を指定して、その署名権限が意図された深さのみに制限されるようにしてください。

定義する最大パス長には、リーフ証明書は含まれません。 前の例では、レベル 4 にある下位 CA はリーフ証明書を発行できますが、その証明書パス内にそれ以上の CA 証明書を含めることはできません。

証明書の有効期間の選択

X.509 証明書の有効期間は、証明書が信頼されて有効である期間を決定する必須フィールドです。 CA 階層を計画する際には、アプリケーションに対して発行するリーフ証明書の優先存続期間からさかのぼって作業します。 次に、CA 証明書の有効期間を判別します。

証明書の有効期間は、その証明書を発行したCAの有効期間以下でなければなりません。 たとえば、有効期間（TTL）を10年に設定してルートCAを作成した場合、その下位にあるすべての中間認証局のTTLは、10年以下でなければなりません。 同様に、中間 CA の TTL が 3 年である場合、すべてのリーフ証明書の TTL は 3 年以下でなければなりません。

1. ユース・ケースに適したリーフ証明書の有効期間を選択します。

   Secrets Manager で作成できるプライベート証明書は、クライアント・アプリケーションやサーバー・アプリケーションなどのエンド・エンティティーに発行できるリーフ証明書と見なされます。 Secrets Manager では、最大有効期間が 3 年または 36 カ月の証明書を作成できます。 リーフ証明書のTTLまたは有効期間を決定したら、 証明書テンプレート を使用してその値を設定します。これにより、新しいリーフ証明書が生成されるたびに、指定したTTLが適用されるようになります。

   リーフ証明書のTTLが短いほど、証明書やその秘密鍵が意図せず漏洩したり、侵害されたりするリスクから、より確実に保護されます。 証明書の有効期間を短くすることは、暗号漏えいの可能性を減らすことを意味しますが、証明書が有効であることを確認するために、証明書をより頻繁にローテーションする必要があります。 不注意による停止を回避するために、プライベート証明書の自動ローテーションをスケジュールに入れることができます。

2. 従属 CA の有効期間を選択します。

   ベストプラクティスとして、下位CA証明書の有効期間を、その証明書が発行する証明書の有効期間よりも大幅に長く設定してください。 親 CA の有効期間を、それが発行する子 CA 証明書またはリーフ証明書の期間の 2 倍から 5 倍に定義します。 例えば、2 レベル CA 階層があり、1 年の TTL を持つリーフ証明書を発行する場合は、3 年の TTL を持つ従属発行 CA を構成します。 ルート CA 証明書を置き換えることなく、常に従属 CA 証明書を更新できます。

3. ルート CA の有効期間を選択します。

   ルート CA 証明書を更新すると、その変更は公開鍵インフラストラクチャー全体に影響します。 影響を最小限に抑えるために、ルート CA 証明書の有効期間を長く設定することをお勧めします。 Secrets Manager では、ルート証明書のデフォルト TTL は 10 年です。

鍵管理サービスの選定

Secrets Manager で認証局（CA）を作成する前に、そのCAの公開鍵と秘密鍵を生成するためのキー管理サービス（KMS）を選択する必要があります。 この場合、CA 公開鍵と秘密鍵はソフトウェアで作成され、サービス内部で管理される。 外部のハードウェア・セキュリティ・モジュール（HSM）で鍵を管理することもできます。Secrets Managerは、IBM Cloud Hyper Protect Crypto Services（HPCS）によるCA鍵の管理をサポートしています。 HPCS秘密鍵ストア内の既存の鍵を使用するようCAを設定することも、Secrets ManagerがCA用に新しい鍵を作成することを許可することもできる。

Secrets Manager プライベート証明書エンジンは、PKCS#11 API を使用して HPCS と通信しています。 認証と認可は、Secrets Manager IAM credentials secretを使って管理されるIAM APIキーを使って行われる。 暗号署名操作は、HPCS内で実行され、CA秘密鍵マテリアルが暗号デバイスから離れることはない。

注： Secrets Manager は、HPCS の鍵を用いた CA 証明書の作成に関連するコストまたは料金の 制限を管理しない。

鍵を生成するためのアルゴリズムの選択

Secrets Manager で認証局を作成する前に、CA の公開鍵と秘密鍵を生成するための鍵アルゴリズムを選択する必要があります。 公開鍵と秘密鍵のペアは、SSL/TLS 接続を認証するために使用されます。 どこから開始すればかわからない場合は、以下の推奨ガイドを使用して鍵アルゴリズムを選択できます。

1. アルゴリズム・ファミリーを選択します。

   選択した鍵アルゴリズムによって、鍵を生成して証明書に署名するために使用する暗号化アルゴリズムと鍵サイズが決まります。 ベスト・プラクティスとして、証明書チェーンに属するすべての証明書に同じアルゴリズム・ファミリーを使用してください。Secrets Manager は、以下のアルゴリズム・ファミリーをサポートしています。

   サポートされるアルゴリズムファミリーとキーサイズ

   アルゴリズム・ファミリー	説明	サポートされる鍵サイズ
   RSA	ほとんどのブラウザーおよびサーバーで広く使用され、互換性がある RSA は、公開鍵暗号方式の業界標準です。	2048 ビット 4096 ビット
   楕円曲線 (EC)	より強力な鍵とより小さい証明書を生成します。 例えば、256ビットのEC鍵は、暗号化の強度の点で3072ビットのRSA鍵と同等です。	224 ビット 256 ビット 384 ビット 521 ビット

2. 鍵サイズを選択します。

   選択した鍵のサイズまたは長さによって、暗号化強度が決まります。 アルゴリズム・ファミリーの鍵サイズが大きいほど、ブレークするのが難しくなります。 鍵の長さが長いほど、保管および送信するデータが多くなり、証明書のパフォーマンスに影響を与える可能性があることに注意してください。 ベスト・プラクティスとして、証明書の TTL または有効期間に適した鍵サイズを選択してください。

   有効期間が長い証明書については、暗号化による保護を強化するため、鍵の長さを長くすることをお勧めします。

証明書失効リストの読み取り

このエンドポイントを使うと、現在の CRL を生の DER エンコード形式で取得できる。 /pem がエンドポイントに追加された場合、CRL は PEM 形式で返される。

GET v1/ibmcloud/private_cert/config/certificate_authorities/:ca-name/crl(/pem)
Response 200 OK
<binary DER-encoded CRL>

リーフ証明書または中間 CA 証明書がリーフ証明書のコンテキストから取り消されていないことを検証するために、 "crl_distribution_points_encoded": true プロパティーを使用して CA を構成できます。 このコンフィギュレーションは、各リーフ証明書または中間 CA 証明書の X509v3 CRL Distribution Points などのプロパティに、発行 CA CRL のダウンロードに使用される URL をエンコードする。 その後、CA バリデーターは、リーフ CA 証明書または中間 CA 証明書が失効しているかどうかを検査できます。

CA 証明書の読み取り

このエンドポイントを使用すると、生の DER エンコード形式で CA 証明書を取得できます。 エンドポイントに /pem が追加されている場合、CA証明書は PEM 形式で返される。

GET v1/ibmcloud/private_cert/config/certificate_authorities/:ca-name/ca(/pem)
Response 200 OK
<binary DER-encoded certificate >

CA 証明書チェーンの読み取り

このエンドポイントでは、 PEM フォーマットの CA を含む CA 証明書チェーンを取得できます。 このエンドポイントはベアです。 標準の Vault データ構造は返されず、Vault CLI は読み取ることができません。

GET v1/ibmcloud/private_cert/config/certificate_authorities/:ca-name/ca_chain
Response 200 OK
<PEM-encoded certificate chain>

CAチェーンがリーフ証明書のコンテキストのものであることを検証するために、 Secrets Manager で、 "issuing_certificates_urls_encoded": true プロパティを使って認証局を設定することができます。 各リーフ証明書または中間 CA 証明書において、このコンフィギュレーションは、発行 CA 証明書のダウン ロードに使用される URL をプロパティ Authority Information Access/CA Issuers にエンコードする。 その後、CA バリデーターは各 CA 証明書を検証できます。