プライベート証明書の作成の準備

プライベート証明書エンジンを構成することで、IBM Cloud® Secrets Manager サービス・インスタンスがプライベート証明書を生成できるようにすることができます。

Secrets Manager では、プライベート証明書エンジンがprivate_certシークレット・タイプのバックエンドとして機能します。プライベート証明書は、サービスで署名、発行、および管理できる SSL/TLS 証明書です。プライベート証明書を作成する前に、認証局（CAデジタル証明書を発行する、信頼できるサード・パーティーの組織または企業。一般に、認証局は、固有の証明書を付与された個人の ID を検証します。）と証明書の有効な信頼チェーンを作成してサービス・インスタンスを有効にする必要があります。

証明書階層についての学習

Secrets Manager を使用すると、署名して SSL/TLS 証明書をアプリケーションに発行できる認証局 (CA) を作成することにより、独自の公開鍵インフラストラクチャー (PKI) システムを構築できます。証明書チェーンを配置すると、Secrets Manager インスタンスを使用して、クライアント・アプリケーションおよびサーバー・アプリケーション用のプライベート証明書を作成できます。

有効な証明書チェーンは、トラステッド・ルート CA から始まり、1 つ以上の従属 CA を通過し、エンド・エンティティー・アプリケーションに発行されるリーフ証明書で終わります。例えば、以下の単純な CA 階層をチェックアウトします。

この図は、第一階層のルート認証局から始まる証明書の3階層構造を示している。 — Example three-level CA hierarchy

ルート CA は、証明書チェーン全体のトラスト・アンカーとして機能します。
レベル 2 の従属 CA は、ルート CA によって署名され、発行されます。これらの従属 CA は、他の従属 CA 証明書に署名します。
最後に、レベル 3 の従属 CA 証明書に署名し、エンド・エンティティー・アプリケーションにリーフ証明書を発行します。

Secrets Manager では、リーフ証明書は、作成してアプリケーションにデプロイするプライベート証明書です。

CA 階層の設計

Secrets Managerを使用すると、サービスインスタンス内に、複数のブランチや階層を含むルートCAを最大10個、中間CAを最大10個作成できます。

認証局オプション
権限タイプ	説明
ルート認証局	証明書チェーンのトラスト・アンカー。証明書の階層では、ルート CA は証明書チェーンの最上部にあります。この CA は、CA に従属する CA (例えば、中間 CA) の証明書に署名するために使用されます。
中間認証局	他の中間 CA 証明書に署名して発行する従属または下位の認証局。中間 CA は、クライアント・アプリケーションやサーバー・アプリケーションなどのエンド・エンティティーにリーフ証明書を発行するためにも使用されます。 Secrets Manager では、内部または外部で署名されたの中間 CA を作成できます。

CA 階層の構造の計画

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

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

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

この図は、第一階層のルート認証局から始まる、証明書の2階層構造を示している。 — Two-level certificate authority hierarchy

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

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

CA 階層の深さの設定

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

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

この図は、第一階層のルート認証局から始まる証明書の4階層構造を示している。 — Three-level certificate authority hierarchy

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

証明書の有効期間の選択

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

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

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

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

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

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

HPCSに鍵を持つCAの作成準備

アカウントにHPCSのインスタンスがプロビジョニングされているはずです。 HPCSインスタンスで、CA鍵に使用するプライベート鍵ストアを作成します。
PKCS #11 Normalユーザータイプの設定については、HPCSドキュメントの指示に従ってください。

カスタムIAMロールの作成
1. 暗号処理を実行するためのカスタムロールを作成する
2. 鍵を管理するカスタム・ロールを作成する
IAMサービスIDの作成
1. 一般ユーザーのサービスIDを作成する

注：サービスIDのAPIキーは作成しないでください。 APIキーはSecrets Managerによって作成・管理されます

サービスIDにIAMロールを割り当てる
1. サービスIDにカスタムロールを割り当てる
2. HPCSインスタンスのサービスIDにViewerロールを割り当てます。

あなたのSecrets Managerインスタンスで：

IAM資格情報エンジンを設定する
新しい IAM 資格情報シークレットを作成し、以下を設定する：
1. Lease duration を設定します
2. Enable Reuse IAM credentials until lease expires enabled
3. Automatic secret rotation を有効にします
4. HPCSとの認証用に作成したサービスIDにアクセスを割り当てる

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

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

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

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

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

鍵サイズを選択します。

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

より長寿命の証明書については、より長い鍵長を使用し、暗号化保護を強化することを推奨する。

認証局非認証エンドポイントの使用

アプリケーション用に Secrets Manager で CA によって発行されたリーフ証明書を使用している場合は、以下の API 呼び出しを使用して、発行元の CA 証明書失効リスト (CRL) および CA 証明書にアクセスできるようにします。

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

このエンドポイントを使用すると、生の DER エンコード形式で現在の CRL を取得できます。 /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 CRL をダウンロードするために使用される URL が、各リーフまたは中間 CA 証明書の X509v3 CRL Distribution Points などのプロパティーにエンコードされます。その後、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 チェーンがリーフ証明書のコンテキストからのものであることを確認するには、プロパティー "issuing_certificates_urls_encoded": true を使用して Secrets Manager で CA を構成します。各リーフ CA 証明書または中間 CA 証明書では、この構成により、発行元 CA 証明書をダウンロードするために使用される URL がプロパティー Authority Information Access/CA Issuers にエンコードされます。その後、CA バリデーターは各 CA 証明書を検証できます。

次のステップ

これで、インスタンスの認証局を作成する準備ができました。