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: 標準の Kubernetes クラスタまたは仮想マシンにユーザー ワークロードがデプロイされる VPC。
  • GDC 内部 DNS: ACME DNS-01 チャレンジの解決に使用されるローカル プライベート DNS ゾーン（環境変数で構成されたプライベート ドメイン名を使用）を管理します。
  • GDC 下り（外向き）NAT ゲートウェイ: クラスタ Pod から外部 EJBCA サーバーの IP アドレスにアウトバウンド トラフィックを転送します。
  • Harbor Private Registry: エアギャップ デプロイ用にミラーリングされたコンテナ イメージ（EJBCA cert-manager 発行元など）をホストします。

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

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

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

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

サービスとロジック

  • EJBCA Enterprise Server: CA 階層（ルートと下位）の管理、証明書リクエストの検証、証明書の署名、監査レコードのロギングを行う外部 CA エンジン（ソフトウェアまたはハードウェア アプライアンス）。
  • ハードウェア セキュリティ モジュール（HSM）: 鍵の生成と証明書の署名を行う CC EAL4+ 準拠の暗号モジュール。CA 秘密鍵が公開されないことを保証します。
  • GDC 内部 DNS: ACME チャレンジ検証サービスが一時的な TXT レコードを介してドメインの所有権を確認するために使用するプライベート DNS ゾーン（ManagedDNSZone と ResourceRecordSet）を管理します。
  • 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 検証サイクルのタイムアウトを防ぐようにサイズ設定する必要があります。
  • セキュリティとコンプライアンス:
    • 外部 HSM 内で CA ルート鍵を分離することで、高いセキュリティとコンプライアンスの基準（BSI VS-NfD など）を満たすことができます。
    • EJBCA への管理アクセスは、ロールベース アクセス制御（RBAC）を使用して厳密に制限し、一意のクライアント証明書シリアル番号にマッピングする必要があります。
  • 可用性と信頼性:
    • 継続的な運用を確保し、単一障害点を回避するには、複数のアベイラビリティ ゾーンにまたがる外部 EJBCA サーバーの高可用性デプロイ（アクティブ - パッシブ構成またはクラスタ構成を使用）をおすすめします。
    • GDC 内に複数の cert-manager コントローラ レプリカをデプロイすると、クラスタ側の自動証明書発行の復元力が維持されます。
  • 運用管理:
    • お客様は、システム パッチ適用、HSM 鍵のローテーション、CRL の公開など、EJBCA サーバーの所有権を保持します。
    • お客様の GDC プラットフォーム管理者は、クラスタ内の cert-manager と EJBCA 発行元コントローラのメンテナンスと、GDC 側の限定公開 DNS レコードの管理を担当します。

設計上の意思決定

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

EJBCA 統合オプション

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

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

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

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

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

前提条件と制限事項

前提条件

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

制限事項

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