CA 階層の構造の計画

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

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

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

3つのレベル：ルート認証局と2つの下位認証局

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

CA 階層の深さの設定

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

一般に、ルート認証局は、その認証パスに作成できる下位認証局の数を制限しないように設定することができる。 しかし、下位認証局に最大パス長を定義することは、認証局の誤った設定を避けるための重要なセキュリ ティ上の措置である。 階層内の従属 CA の配置に応じて、最大パス長を指定して、その署名権限が意図された深さのみに制限されるようにしてください。

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

証明書の有効期間の選択

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

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

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

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

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

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

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

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

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

鍵管理サービスの選択

Secrets Manager で認証局を作成する前に、認証局の公開鍵と秘密鍵を生成するための鍵管理サービス（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 証明書を検証できます。