Keyfactor EJBCA-Referenzarchitektur

Übersicht

In dieser Referenzarchitektur wird das konzeptionelle Design für die Integration von Keyfactor EJBCA Enterprise als Drittanbieter-Zertifizierungsstelle (Certificate Authority, CA) in Google Distributed Cloud (GDC) mit Air Gap definiert.

Keyfactor EJBCA Enterprise ist eine hochskalierbare, robuste und FIPS-konforme Zertifizierungsstellenplattform, mit der Unternehmen die Public-Key-Infrastruktur (PKI) in heterogenen Umgebungen verwalten können.

GDC mit Air Gap umfasst einen nativen Certificate Authority Service für die automatisierte Schlüssel- und Zertifikatsverwaltung innerhalb der gehosteten Cloud-Grenze. Der native CA-Dienst ist die empfohlene Lösung für die meisten Kunden, da er vollständig verwaltete, nahtlose PKI-Funktionen innerhalb der Plattform bietet. Organisationen, die ihre PKI-Infrastruktur für vorhandene Arbeitslasten außerhalb von GDC auf Keyfactor EJBCA standardisiert haben, bevorzugen jedoch möglicherweise dieselbe konsistente CA-Architektur und dieselben Verwaltungsrichtlinien für Arbeitslasten, die in ihren GDC-Umgebungen ausgeführt werden.

Funktionen

Die Lösung bietet mehrere zentrale Funktionskomponenten für die Verwaltung des Zertifikatslebenszyklus:

• Automatisiertes Zertifikatslebenszyklus-Management: Nutzen Sie den benutzerdefinierten EJBCA-Aussteller in GDC-Standardclustern, um die Bereitstellung, Erneuerung und den Widerruf von Serverzertifikaten über cert-manager zu automatisieren.
• Standardisierte ACME-Automatisierung: Unterstützung des ACME-Protokolls (Automatic Certificate Management Environment) mit DNS-01-Challenges, sodass Plattformdienste Zertifikate nahtlos anfordern und verlängern können.
• Sichere HSM-Integration: Direkter kryptografischer Schutz aller privaten CA-Schlüssel in einem CC EAL4+-zertifizierten Hardware Security Module (HSM). Dadurch wird sichergestellt, dass Schlüsselmaterial die physische Sicherheitsgrenze nie verlässt. Keyfactor EJBCA Enterprise kann entweder ein eigenes verwaltetes HSM verwenden oder eine Verbindung zu einem externen HSM herstellen.
• Kompatibilität mit Air Gap: Spezielle Workflows zum Spiegeln des EJBCA-cert-manager-Aussteller-Images aus öffentlichen Registries in die private Harbor-Registry von GDC, um die Offlineverfügbarkeit zu gewährleisten.
• Isolation des ausgehenden Traffics: Konfiguration des ausgehenden Netzwerks mit GDC-Subnetz- und CloudNATGateway-Ressourcen, um den GDC API-Traffic direkt auf die externe EJBCA-Server-IP-Adresse zu beschränken.

Architekturprinzipien

• Modell der gemeinsamen Verantwortung: Der Kunde betreibt den externen EJBCA-Server und das HSM und ist Eigentümer der physischen PKI-Infrastruktur und der CA-Stammschlüssel. GDC stellt die Compute-, internen DNS- und automatisierten Client-Ebenen innerhalb des Standardclusters bereit.
• Sicherheitsorientiertes Design: Erfüllt die Sicherheitsanforderungen für Air-Gap-Umgebungen, indem lokale Container-Image-Spiegel verwendet und strenge Regeln für ausgehenden Traffic erzwungen werden, um die Angriffsfläche im Netzwerk zu minimieren.
• Protokollstandardisierung: Priorisiert Standardprotokolle (ACME und mTLS REST) für die Interaktion mit der Zertifizierungsstelle, um proprietäre API-Abhängigkeiten zu vermeiden und flexible Clientintegrationen zu ermöglichen.

Architektur

Die Architektur folgt dem Modell der externen Zertifizierungsstelle, bei dem der EJBCA-Server und das zugrunde liegende Hardwaresicherheitsmodul (HSM) extern außerhalb der physischen GDC-Grenzen gehostet werden, aber über das Netzwerk zugänglich sind. Der EJBCA-Server kann extern entweder als Hardware- oder Software-Appliance bereitgestellt werden. Für die in diesem Leitfaden beschriebene Kernintegration ist nur erforderlich, dass der externe EJBCA-Server über eine stabile IP-Adresse erreichbar ist.

Zu den wichtigsten Komponenten dieser Architektur gehören:

• EJBCA Enterprise Server: Wird extern entweder als Keyfactor-Hardware-Appliance oder als Software-Appliance bereitgestellt, die die Zertifizierungsstellen (Stamm- und untergeordnete Zertifizierungsstellen) enthält und alle Zertifizierungsstellenschlüssel in einem CC EAL4+-zertifizierten HSM generiert.
• Standard-VPC: VPC, in der Nutzerarbeitslasten entweder in Standard-Kubernetes-Clustern oder in virtuellen Maschinen bereitgestellt werden.
• Internes GDC-DNS: Verwaltet lokale private DNS-Zonen (mit dem in den Umgebungsvariablen konfigurierten privaten Domainnamen), die zum Auflösen von ACME-DNS-01-Challenges verwendet werden.
• GDC-NAT-Gateway für ausgehenden Traffic: Leitet ausgehenden Traffic von Cluster-Pods an die externe IP-Adresse des EJBCA-Servers weiter.
• Private Harbor-Registry: Hostet gespiegelte Container-Images (z. B. den EJBCA-cert-manager-Aussteller) für die Bereitstellung mit Air Gap.

Konzepte und Technologien

In diesem Abschnitt werden die funktionalen Komponenten, ihre Aufgaben und die Kommunikation innerhalb des Systems beschrieben.

Infrastruktur und Plattform

• GDC-Standardcluster: Die primäre Compute-Umgebung, in der sich die EJBCA-Aussteller- und cert-manager-Pods befinden und die Zertifikatsautomatisierung für Arbeitslasten ausführen.
• Harbor Registry: Die sichere, lokale „Source of Truth“ für alle Container-Images in GDC. Es bietet automatisierte Scans, um sicherzustellen, dass Images vor der Bereitstellung frei von bekannten Sicherheitslücken sind.
• GDC-Egress-Gateway: Plattformnative Netzwerkressourcen (Subnetz und CloudNATGateway), die ausgehenden API-Traffic von Cluster-Pods zum externen CA-Server steuern und sichern.

Dienste und Logik

• EJBCA Enterprise Server: Die externe CA-Engine (Software- oder Hardware-Appliance), die für die Verwaltung von CA-Hierarchien (Root und Subordinate), die Validierung von Zertifikatsanfragen, das Signieren von Zertifikaten und das Protokollieren von Audit-Datensätzen verantwortlich ist.
• Hardware-Sicherheitsmodul (HSM): Das CC EAL4+-konforme kryptografische Modul, das die Schlüsselgenerierung und Zertifikatsignierung übernimmt und dafür sorgt, dass private Schlüssel der Zertifizierungsstelle nie offengelegt werden.
• Internes GDC-DNS: Verwaltet private DNS-Zonen (ManagedDNSZone und ResourceRecordSet), die vom ACME-Challenge-Validierungsdienst verwendet werden, um die Domaininhaberschaft über temporäre TXT-Einträge zu bestätigen.
• cert-manager mit EJBCA-Aussteller: Der Kubernetes-native Zertifikatscontroller, der Zertifikatsanfragen abfängt und den EJBCA-Aussteller verwendet, um sie in sichere EJBCA API-Aufrufe zu übersetzen.

Datenfluss und Schnittstellen

• ACME-Protokoll: Die Standard-API-Schnittstelle für die automatisierte, domainvalidierte Ausstellung von Serverzertifikaten mithilfe der DNS-01-Challenge.
• EJBCA REST API: Die RESTful-Schnittstelle, die für das administrative Bootstrapping und programmatische Vorgänge (z. B. CSR-Signierung und -Widerruf) verwendet wird.
• mTLS-Clientauthentifizierung: Der primäre Authentifizierungsmechanismus für die cert-manager-Integration, bei dem die Clientidentität über gegenseitiges TLS mit dedizierten Clientzertifikaten überprüft wird.

Hinweise

• Skalierbarkeit und Leistung:
  • Der externe EJBCA-Server muss skaliert werden (CPU, Arbeitsspeicher, HSM-Kapazität), um gleichzeitige Validierungs- und Signierungsanfragen zu verarbeiten, insbesondere bei Profilen mit hoher Ausstellungsrate.
  • Die GDC-Ressourcen für das Ausgangsgateway müssen so dimensioniert sein, dass die Latenz zum externen CA-Server minimal ist, um Zeitüberschreitungen während der Validierungszyklen des cert-managers zu vermeiden.
• Sicherheit und Compliance:
  • Durch die Isolierung der CA-Stammschlüssel in einem externen HSM werden hohe Sicherheits- und Compliance-Standards (z. B. BSI VS-NfD) erfüllt.
  • Der Administratorzugriff auf EJBCA sollte mithilfe der rollenbasierten Zugriffssteuerung (Role-Based Access Control, RBAC) streng eingeschränkt und eindeutigen Seriennummern von Clientzertifikaten zugeordnet werden.
• Verfügbarkeit und Zuverlässigkeit:
  • Eine hochverfügbare Bereitstellung des externen EJBCA-Servers über mehrere Verfügbarkeitszonen hinweg (mit einer Aktiv/Passiv- oder Clusterkonfiguration) wird empfohlen, um einen kontinuierlichen Betrieb zu gewährleisten und einen Single Point of Failure zu vermeiden.
  • Durch die Bereitstellung mehrerer cert-manager-Controller-Replikate in GDC wird sichergestellt, dass die clusterseitige automatisierte Zertifikatsausstellung stabil bleibt.
• Betriebsmanagement:
  • Der Kunde bleibt Eigentümer des EJBCA-Servers, einschließlich System-Patching, HSM-Schlüsselrotation und CRL-Veröffentlichung.
  • Die GDC-Plattformadministratoren des Kunden sind für die Wartung des clusterinternen cert-managers und des EJBCA-Aussteller-Controllers sowie für die Verwaltung der privaten DNS-Einträge auf GDC-Seite verantwortlich.

Designentscheidung

Die wichtigsten Architekturentscheidungen für diese Lösung konzentrieren sich darauf, die Automatisierung mit den Einschränkungen der Air-Gap-Umgebung in Einklang zu bringen.

EJBCA-Integrationsoption

Der native Certificate Authority Service von GDC ist die empfohlene PKI-Lösung für die meisten Kunden. Er bietet vollständig verwaltete, nahtlose PKI-Funktionen in GDC-Umgebungen mit Air Gap. Für Organisationen, die ihre PKI-Infrastruktur bereits auf Keyfactor EJBCA für Arbeitslasten außerhalb von GDC standardisiert haben, wird die Integration ihres vorhandenen externen CA-Servers als Opt-in-Option angeboten. So können sie etablierte PKI-Vorlagen, Sicherheitsrichtlinien und Betriebsmodelle wiederverwenden, ohne ihre Vertrauenshierarchie neu zu gestalten oder wichtige Workflows zu migrieren.

Optionen für die ACME-Challenge-Validierung

Sowohl die ACME-Validierungsprotokolle HTTP-01 als auch DNS-01 werden vollständig unterstützt. In diesem Architekturleitfaden wird die DNS-01-Anforderung mit dem internen DNS von GDC hervorgehoben, das sich ideal für isolierte, private Umgebungen eignet, die keinen eingehenden öffentlichen HTTP-Traffic unterstützen. Kunden können jedoch je nach ihrer spezifischen Netzwerktopologie, ihren Sicherheitsrichtlinien und ihren Arbeitslastanforderungen eine der beiden Validierungsmethoden auswählen.

Empfehlung für mTLS-Verwaltungskanal

Die Verwendung von gegenseitigem TLS (mTLS) wird als robuste Authentifizierungsmethode für cert-manager und Integrationsclients empfohlen. mTLS bietet eine hochsichere, kryptografische Überprüfung der Clientidentität mithilfe von Clientzertifikaten. Der Kunde kann jedoch auch andere Authentifizierungsmechanismen konfigurieren, die von seiner EJBCA-Instanz gemäß seinen Unternehmenssicherheitsrichtlinien unterstützt werden.

Annahmen und Einschränkungen

Annahmen

• Der externe EJBCA-Server ist bereitgestellt, konfiguriert und über eine stabile IP-Adresse erreichbar.
• Der EJBCA-Server ist mit den erforderlichen Root- und untergeordneten Zertifizierungsstellen sowie den entsprechenden Endentitätsprofilen vorkonfiguriert.
• Es ist ein sicherer Mechanismus (z. B. ein Bastion-Knoten oder ein Offline-Übertragungsworkflow) verfügbar, um das Container-Image des EJBCA-Ausstellers in der GDC Harbor-Registry zu veröffentlichen.
• In Standard-Kubernetes-Clustern in GDC ist cert-manager vorinstalliert oder für den Betrieb konfiguriert.

Beschränkungen

• Wartung von externem HSM und EJBCA: Die GDC-Steuerungsebene verwaltet weder den externen EJBCA-Server noch das zugrunde liegende HSM. Lebenszyklusvorgänge (Sicherungen, Upgrades, Schlüsselrotationen) werden vom PKI-Betriebsteam des Kunden ausgeführt.
• DNSSEC-Validierungseinschränkung: Da privates internes DNS verwendet wird, muss die DNSSEC-Validierung serverseitig in der ACME-Konfiguration deaktiviert werden, um Auflösungsfehler für lokale private Domains zu vermeiden.
• Abhängigkeit der ausgehenden Verbindung: Die automatisierten Dienste zur Zertifikatsausstellung hängen von der Verfügbarkeit und Latenz der Netzwerkverbindung zwischen dem GDC-Rack und dem externen EJBCA-Server ab.