Keyfactor EJBCA-Referenzarchitektur

Übersicht

Diese Referenzarchitektur definiert das konzeptionelle Design für die Einbindung von Keyfactor EJBCA Enterprise als Zertifizierungsstelle eines Drittanbieters in Google Distributed Cloud (GDC) mit Air-Gap.

Keyfactor EJBCA Enterprise ist eine hochgradig skalierbare, 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 Zertifizierungsstellendienst für die automatisierte Schlüssel- und Zertifikatsverwaltung innerhalb der gehosteten Cloudgrenze. Der native Zertifizierungsstellendienst ist die empfohlene Lösung für die meisten Kunden, da er vollständig verwaltete, nahtlose PKI-Funktionen innerhalb der Plattform bietet. Unternehmen, die ihre PKI-Infrastruktur für vorhandene Arbeitslasten außerhalb von GDC auf Keyfactor EJBCA standardisiert haben, bevorzugen möglicherweise dieselbe konsistente Zertifizierungsstellenarchitektur und dieselben Verwaltungsrichtlinien für Arbeitslasten, die in ihren GDC-Umgebungen ausgeführt werden.

Funktionen

Die Lösung bietet mehrere funktionale Kernkomponenten für die Verwaltung des Zertifikatslebenszyklus:

• Automatisierte Verwaltung des Zertifikatslebenszyklus: Nutzen Sie den benutzerdefinierten EJBCA Aussteller in GDC-Standardclustern, um die Bereitstellung, Verlängerung und Sperrung von Serverzertifikaten über cert-manager zu automatisieren.
• Standardisierte ACME-Automatisierung: Unterstützung für das ACME-Protokoll (Automatic Certificate Management Environment) mit DNS-01-Herausforderungen, sodass Plattformdienste Zertifikate nahtlos anfordern und verlängern können.
• Sichere HSM-Integration: Direkter kryptografischer Schutz aller privaten Zertifizierungsstellenschlüssel in einem CC EAL4+-zertifizierten Hardwaresicherheitsmodul (HSM), sodass Schlüsselmaterial die physische Sicherheitsgrenze niemals verlässt. Keyfactor EJBCA Enterprise kann entweder ein eigenes verwaltetes HSM verwenden oder eine Verbindung zu einem externen HSM herstellen.
• Air-Gap-Kompatibilität: Spezialisierte Workflows zum Spiegeln des EJBCA cert-manager-Aussteller-Images aus öffentlichen Registries in die private Harbor-Registry von GDC, um die Offline verfügbarkeit zu gewährleisten.
• Isolation des ausgehenden Traffics: Ausgehende Netzwerkkonfiguration mit GDC-Subnetz- und CloudNATGateway-Ressourcen, um den GDC-API-Traffic direkt auf die externe IP-Adresse des EJBCA-Servers 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 Zertifizierungsstellen-Stammschlüssel. GDC stellt die Compute-, internen DNS- und automatisierten Clientschichten innerhalb des Standardclusters bereit.
• Sicherheitsorientiertes Design: Entspricht den Sicherheitsanforderungen für Air-Gap-Umgebungen durch die Verwendung lokaler Container-Image-Spiegel und die Erzwingung einer strengen Ausgangssteuerung , um die Angriffsfläche des Netzwerks zu minimieren.
• Protokollstandardisierung: Priorisiert Standardprotokolle (ACME und mTLS REST) für die Interaktion mit der Zertifizierungsstelle, vermeidet proprietäre API-Abhängigkeiten und ermöglicht flexible Clientintegrationen.

Architektur

Die Architektur folgt dem Modell der externen Zertifizierungsstelle, bei dem der EJBCA-Server und das zugehörige 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 dieser Anleitung 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: Extern entweder als Keyfactor Hardware-Appliance oder Software-Appliance bereitgestellt, die die Zertifizierungsstellen (Stamm- und untergeordnete) enthält und das gesamte Zertifizierungsstellen-Schlüsselmaterial 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 DNS von GDC: Verwaltet lokale private DNS Zonen (mit dem in den Umgebungsvariablen konfigurierten privaten Domainnamen), die zum Auflösen von ACME DNS-01-Herausforderungen verwendet werden.
• Ausgangs-NAT-Gateway von GDC: 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 Verantwortlichkeiten und die Art und Weise beschrieben, wie sie innerhalb des Systems kommunizieren.

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 ausgeführt wird.
• Harbor-Registry: Die sichere, lokale „Source of Truth“ für alle Container Images in GDC. Sie bietet automatisierte Scans, um sicherzustellen, dass Images vor der Bereitstellung keine bekannten Sicherheitslücken aufweisen.
• Ausgangs-Gateway von GDC: Plattformnative Netzwerkressourcen (Subnetz und CloudNATGateway), die den ausgehenden API-Traffic von Cluster-Pods zum externen Zertifizierungsstellenserver steuern und schützen.

Dienste und Logik

• EJBCA Enterprise Server: Die externe Zertifizierungsstellen-Engine (Software- oder Hardware- Appliance), die für die Verwaltung von Zertifizierungsstellenhierarchien (Stamm- und untergeordnete), die Validierung von Zertifikatsanfragen, die Signierung von Zertifikaten und die Protokollierung von Audit- Logs verantwortlich ist.
• Hardwaresicherheitsmodul (HSM): Das CC EAL4+-konforme kryptografische Modul, das die Schlüsselgenerierung und die Zertifikatsignierung übernimmt und dafür sorgt, dass private Zertifizierungsstellenschlüssel niemals offengelegt werden.
• Internes DNS von GDC: Verwaltet private DNS-Zonen (ManagedDNSZone und ResourceRecordSet), die vom ACME-Dienst zur Validierung von Herausforderungen verwendet werden, um die Domaininhaberschaft über temporäre TXT-Einträge zu bestätigen.
• cert-manager mit EJBCA-Aussteller: Der Kubernetes-native Zertifikats controller, der Zertifikatsanfragen abfängt und den EJBCA Aussteller verwendet, um sie in sichere EJBCA-API-Aufrufe zu übersetzen.

Datenfluss und Schnittstellen

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

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 Ressourcen des Ausgangs-Gateways von GDC müssen so dimensioniert sein, dass die Latenz zum externen Zertifizierungsstellenserver minimal ist, um Zeitüberschreitungen während der cert-manager-Validierungszyklen zu vermeiden.
• Sicherheit und Compliance:
  • Die Isolation der Zertifizierungsstellen-Stammschlüssel in einem externen HSM erfüllt hohe Sicherheits- und Compliance-Standards (z. B. BSI VS-NfD).
  • Der administrative Zugriff auf EJBCA sollte mithilfe der rollenbasierten Zugriffssteuerung (Role-based Access Control, RBAC) streng begrenzt und eindeutigen Seriennummern von Clientzertifikaten zugeordnet werden.
• Verfügbarkeit und Zuverlässigkeit:
  • Die Bereitstellung des externen EJBCA-Servers mit Hochverfügbarkeit in mehreren Verfügbarkeitszonen (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 automatisierte Zertifikatsausstellung auf Clusterseite robust 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 cert-manager- und EJBCA-Aussteller-Controllers im Cluster und die Verwaltung der privaten DNS-Einträge auf GDC-Seite verantwortlich.

Designentscheidung

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

Option für die EJBCA-Integration

Der native Zertifizierungsstellendienst von GDC ist die empfohlene PKI-Lösung für die meisten Kunden, da er vollständig verwaltete, nahtlose PKI-Funktionen in GDC-Umgebungen mit Air-Gap bietet. Für Unternehmen, die ihre PKI-Infrastruktur für Arbeitslasten außerhalb von GDC bereits auf Keyfactor EJBCA standardisiert haben, wird die Einbindung ihres vorhandenen externen Zertifizierungsstellenservers als optionale 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-Herausforderungsvalidierung

Sowohl die HTTP-01- als auch die DNS-01-ACME-Herausforderungsvalidierungsprotokolle werden vollständig unterstützt. In dieser Architekturleitfaden wird die DNS-01-Herausforderung 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 den administrativen mTLS-Kanal

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 andere Authentifizierungsmechanismen konfigurieren, die von seiner EJBCA-Instanz unterstützt werden, und zwar gemäß seinen Unternehmenssicherheitsrichtlinien.

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 Stamm- und untergeordneten Zertifizierungsstellen sowie den entsprechenden End Entity-Profilen vorkonfiguriert.
• Ein sicherer Mechanismus (z. B. ein Bastion-Knoten oder ein Offline-Übertragungsworkflow) ist verfügbar, um das EJBCA-Aussteller-Container-Image in der GDC-Harbor-Registry zu veröffentlichen.
• In Standard-Kubernetes-Clustern in GDC ist cert-manager vorinstalliert oder für den Betrieb konfiguriert.

Einschränkungen

• Wartung von externem HSM und EJBCA: Die GDC-Steuerungsebene verwaltet nicht den externen EJBCA-Server oder das zugehörige HSM. Lebenszyklusvorgänge (Back-ups, Upgrades, Schlüsselrotationen) werden vom PKI-Betriebsteam des Kunden ausgeführt.
• Einschränkung der DNSSEC-Validierung: 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 von der Ausgangskonnektivität: Die automatisierten Dienste zur Zertifikatsausstellung sind von der Verfügbarkeit und Latenz der Netzwerkverbindung zwischen dem GDC-Rack und dem externen EJBCA-Server abhängig.