Keyfactor EJBCA リファレンス アーキテクチャ

概要

このリファレンス アーキテクチャでは、Google Distributed Cloud（GDC）エアギャップにサードパーティの認証局（CA）として Keyfactor EJBCA Enterprise を統合するためのコンセプト設計を定義します。

Keyfactor EJBCA Enterprise は、拡張性に優れた堅牢な FIPS 準拠の認証局プラットフォームです。これにより、組織は異種環境全体で公開鍵基盤（PKI）を管理できます。

GDC エアギャップには、ホストされたクラウド境界内で鍵と証明書の管理を自動化するためのネイティブ認証局サービスが含まれています。ネイティブ CA サービスは、ほとんどのお客様におすすめのソリューションです。プラットフォーム内でフルマネージドのシームレスな PKI 機能を提供します。ただし、GDC 外の既存のワークロードに対して Keyfactor EJBCA で PKI インフラストラクチャを標準化している組織は、GDC 環境内で実行されるワークロードに同じ一貫した CA アーキテクチャと管理ポリシーを活用することを好む場合があります。

特長と機能

このソリューションには、証明書のライフサイクル管理のためのいくつかのコア機能コンポーネントが用意されています。

  • 証明書のライフサイクル管理の自動化: GDC 標準クラスタ内のカスタム EJBCA 発行者を利用して、cert-manager を介してサーバー証明書のプロビジョニング、更新、取り消しを自動化します。
  • 標準化された ACME 自動化: DNS-01 チャレンジを使用した自動証明書管理環境（ACME）プロトコルのサポート。これにより、プラットフォーム サービスは証明書をシームレスにリクエストして更新できます。
  • 安全な HSM 統合: CC EAL4+ 認定のハードウェア セキュリティ モジュール（HSM）内で、すべての CA 秘密鍵を直接暗号化して保護します。これにより、鍵マテリアルが物理的なセキュリティ境界から漏洩することはありません。Keyfactor EJBCA Enterprise は、独自のマネージド HSM を使用するか、外部 HSM に接続します。
  • エアギャップ互換性: EJBCA cert-manager 発行元イメージをパブリック レジストリから GDC プライベート Harbor レジストリにミラーリングするための専用ワークフロー。オフラインでの可用性を確保します。
  • 下り（外向き）トラフィックの分離: GDC サブネットと CloudNATGateway リソースを使用したアウトバウンド ネットワーク構成。GDC API トラフィックを外部 EJBCA サーバーの IP アドレスに直接制限します。

アーキテクチャの原則

  • 責任の共有モデル: お客様は外部 EJBCA サーバーと HSM を運用し、物理 PKI インフラストラクチャと CA ルート鍵を所有します。一方、GDC は標準クラスタ内でコンピュート、内部 DNS、自動クライアント レイヤを提供します。
  • セキュリティ重視の設計: ローカル コンテナ イメージ ミラーを利用し、厳格な下り（外向き）ゲートを適用してネットワーク攻撃対象領域を最小限に抑えることで、エアギャップ セキュリティ要件に準拠します。
  • プロトコルの標準化: CA とのやり取りに標準プロトコル（ACME と mTLS REST）を優先し、独自の API 依存関係を回避して、柔軟なクライアント統合を可能にします。

アーキテクチャ

このアーキテクチャは外部認証局モデルに従っています。このモデルでは、EJBCA サーバーとそのバックアップ ハードウェア セキュリティ モジュール（HSM）は、物理的な GDC 境界の外でホストされますが、ネットワーク経由でアクセスできます。EJBCA サーバーは、ハードウェアまたはソフトウェア アプライアンスとして外部にデプロイできます。このガイドで説明するコア統合では、外部 EJBCA サーバーに安定した IP アドレスを介して到達できることのみが必要です。

Keyfactor EJBCA のアーキテクチャ図。

このアーキテクチャの主なコンポーネントは次のとおりです。

  • EJBCA Enterprise Server: Keyfactor ハードウェア アプライアンスまたはソフトウェア アプライアンスとして外部にデプロイされ、CA（ルートと下位）を格納し、CC EAL4+ 認定 HSM 内ですべての CA 鍵マテリアルを生成します。
  • デフォルトの VPC: ユーザー ワークロードがデプロイされる VPC。標準の Kubernetes クラスタまたは仮想マシンにデプロイされます。
  • GDC 内部 DNS: ACME DNS-01 チャレンジの解決に使用されるローカルのプライベート DNS ゾーン（環境変数で構成されたプライベート ドメイン名を使用）を管理します。
  • GDC Egress NAT Gateway: クラスタ Pod から外部 EJBCA サーバーの IP アドレスにアウトバウンド トラフィックを転送します。
  • Harbor Private Registry: エアギャップ デプロイ用のミラーリングされたコンテナ イメージ（EJBCA cert-manager 発行者など）をホストします。

コンセプトとテクノロジー

このセクションでは、機能コンポーネント、その役割、システム内での通信方法について詳しく説明します。

インフラストラクチャとプラットフォーム

  • GDC Standard クラスタ: EJBCA 発行者と cert-manager Pod が存在するプライマリ コンピューティング環境。ワークロードの証明書の自動化を実行します。
  • Harbor Registry: GDC 内のすべてのコンテナ イメージの安全なローカルの信頼できる情報源。自動スキャンにより、デプロイ前にイメージに既知の脆弱性がないことを確認できます。
  • GDC Egress Gateway: クラスタ Pod から外部 CA サーバーへのアウトバウンド API トラフィックを管理、保護するプラットフォーム ネイティブのネットワーキング リソース（サブネットと CloudNATGateway）。

サービスとロジック

  • EJBCA Enterprise Server: CA 階層（ルートと下位）の管理、証明書リクエストの検証、証明書の署名、監査レコードのロギングを行う外部 CA エンジン（ソフトウェアまたはハードウェア アプライアンス）。
  • ハードウェア セキュリティ モジュール（HSM）: 鍵の生成と証明書の署名を処理する CC EAL4+ 準拠の暗号モジュール。CA 秘密鍵が公開されることはありません。
  • GDC 内部 DNS: ACME チャレンジ検証サービスで使用されるプライベート DNS ゾーン（ManagedDNSZone と ResourceRecordSet）を管理し、一時的な TXT レコードを介してドメインの所有権を確認します。
  • EJBCA 発行元を使用した cert-manager: 証明書リクエストをインターセプトし、EJBCA 発行元を利用して安全な EJBCA API 呼び出しに変換する Kubernetes ネイティブの証明書コントローラ。

データフローとインターフェース

  • ACME プロトコル: DNS-01 チャレンジを使用して、ドメイン検証済みのサーバー証明書を自動的に発行するための標準 API インターフェース。
  • EJBCA REST API: 管理ブートストラップとプログラムによるオペレーション（CSR の署名や取り消しなど）に使用される RESTful インターフェース。
  • mTLS クライアント認証: cert-manager 統合の主な認証メカニズム。専用のクライアント証明書を使用して相互 TLS 経由でクライアント ID を検証します。

考慮事項

  • スケーラビリティとパフォーマンス:
    • 外部 EJBCA サーバーは、特にバースト発行プロファイル中に、同時検証リクエストと署名付きリクエストを処理できるようにスケーリング（CPU、メモリ、HSM 容量）する必要があります。
    • GDC 下り（外向き）ゲートウェイ リソースは、外部 CA サーバーへのレイテンシを最小限に抑え、cert-manager の検証サイクル中のタイムアウトを防ぐようにサイズ設定する必要があります。
  • セキュリティとコンプライアンス:
    • CA ルート鍵を外部 HSM 内に分離することで、高いセキュリティとコンプライアンス基準（BSI VS-NfD など）を満たすことができます。
    • EJBCA への管理者権限は、ロールベース アクセス制御（RBAC）を使用して厳密に制限し、一意のクライアント証明書のシリアル番号にマッピングする必要があります。
  • 可用性と信頼性:
    • 継続的な運用を確保し、単一障害点を回避するために、複数のアベイラビリティ ゾーンに外部 EJBCA サーバーを高可用性デプロイ（アクティブ / パッシブ構成またはクラスタ構成を使用）することをおすすめします。
    • GDC 内に複数の cert-manager コントローラ レプリカをデプロイすると、クラスタ側の自動証明書発行の復元力が維持されます。
  • 運用管理:
    • お客様は、システム パッチ、HSM 鍵のローテーション、CRL の公開など、EJBCA サーバーの所有権を保持します。
    • お客様の GDC プラットフォーム管理者は、クラスタ内の cert-manager と EJBCA 発行者コントローラのメンテナンス、および GDC 側のプライベート DNS レコードの管理を担当します。

設計上の意思決定

このソリューションの主なアーキテクチャ上の選択は、自動化とエアギャップ環境の制約のバランスを取ることに重点を置いています。

EJBCA 統合オプション

GDC のネイティブ認証局サービスは、ほとんどのお客様に推奨される PKI ソリューションです。GDC エアギャップ環境内でフルマネージドのシームレスな PKI 機能を提供します。ただし、GDC 以外のワークロードで Keyfactor EJBCA の PKI インフラストラクチャをすでに標準化している組織では、既存の外部 CA サーバーを統合するオプションが提供されています。これにより、信頼階層を再設計したり、コア ワークフローを移行したりすることなく、確立された PKI テンプレート、セキュリティ ポリシー、運用モデルを再利用できます。

ACME チャレンジ検証オプション

HTTP-01 と DNS-01 の両方の ACME チャレンジ検証プロトコルが完全にサポートされています。このアーキテクチャ ガイドでは、GDC の内部 DNS を使用した DNS-01 チャレンジに焦点を当てています（これは、インバウンドのパブリック HTTP トラフィックをサポートできない、分離されたプライベート環境に最適です）。ただし、お客様は、特定のネットワーク トポロジ、セキュリティ ポリシー、ワークロード要件に基づいて、いずれかの検証方法を選択できます。

mTLS 管理チャネルの推奨事項

cert-manager と統合クライアントの堅牢な認証方法として、相互 TLS（mTLS）を使用することをおすすめします。mTLS は、クライアント証明書を活用して、クライアント ID の高度に安全な暗号検証を提供します。ただし、お客様は、企業のセキュリティ ポリシーに従って、EJBCA インスタンスでサポートされている他の認証メカニズムを構成することもできます。

前提条件と制限事項

前提条件

  • 外部 EJBCA サーバーがデプロイ、構成され、安定した IP アドレスを介して到達可能である。
  • EJBCA サーバーは、必要なルート CA と下位 CA、および適切なエンド エンティティ プロファイルで事前構成されています。
  • EJBCA 発行者コンテナ イメージを GDC Harbor レジストリに公開するために、安全なメカニズム（踏み台ノードやオフライン転送ワークフローなど）を使用できる。
  • GDC 内の標準 Kubernetes クラスタには、cert-manager がプリインストールされているか、運用用に構成されています。

制限事項

  • 外部 HSM と EJBCA のメンテナンス: GDC コントロール プレーンは、外部 EJBCA サーバーまたはそのバックアップ HSM を管理しません。ライフサイクル オペレーション（バックアップ、アップグレード、鍵のローテーション）は、お客様の PKI オペレーション チームによって処理されます。
  • DNSSEC 検証の制約: プライベート内部 DNS が使用されるため、ローカル プライベート ドメインの解決エラーを回避するには、ACME 構成でサーバーサイドの DNSSEC 検証を無効にする必要があります。
  • 下り（外向き）接続の依存関係: 自動証明書発行サービスは、GDC ラックと外部 EJBCA サーバー間のネットワーク リンクの可用性とレイテンシに依存します。