Diese Seite wurde von der Cloud Translation API übersetzt.

Best Practices für Certificate Manager

Auf dieser Seite werden verschiedene Best Practices für die Konfiguration und Verwaltung von Zertifikaten auf Google Cloud mit Certificate Manager und dem Certificate Authority Service (CA Service) beschrieben. Auf dieser Seite wird beschrieben, wie Sie Ihre Architektur für die Zertifikatsverwaltung entwerfen.

Bevor Sie diese Seite lesen, sollten Sie sich mit der Certificate Manager-Übersicht und der Certificate Authority Service-Übersicht vertraut machen.

Architektur für die Zertifikatsverwaltung entwerfen

Wenn Sie eine Strategie für die Zertifikatsverwaltung für Unternehmen entwerfen, müssen Sie die wichtigsten Anwendungsfälle Ihrer Organisation und den gesamten Lebenszyklus Ihrer Zertifikate berücksichtigen. Diese Entscheidungen wirken sich auf die Kosten, den Betriebsaufwand und die einfache Implementierung von Funktionen zur Zertifikatsverwaltung wie Ausstellung, Sperrung und Rotation aus.

In den folgenden Abschnitten werden unsere Empfehlungen für die einzelnen Designentscheidungen erläutert.

Zertifikattyp auswählen

Beim Erstellen eines Zertifikats müssen Sie einen Zertifikatstyp auswählen, der je nach den Anforderungen Ihrer Anwendung und den Sicherheitsrichtlinien Ihrer Organisation für Ihren Anwendungsfall geeignet ist.

Das folgende Flussdiagramm hilft Ihnen bei der Entscheidung, welcher Zertifikattyp für Sie am besten geeignet ist:

Wählen Sie den geeigneten Zertifikatstyp aus. — Bewerten Sie, welcher Zertifikatstyp ausgewählt werden soll (zum Vergrößern klicken).

Hier sind einige hilfreiche Dokumentationslinks zu den im Flussdiagramm erwähnten Themen:

Hierarchie des Private CA Service optimieren

Wir empfehlen, die Hierarchie Ihres CA-Dienstes so einfach wie möglich zu halten, um einen reibungslosen Betrieb und eine einfache Fehlerbehebung zu gewährleisten. Sie müssen Ihre Stammzertifizierungsstelle in einem eigenen Google-Projekt speichern. Die Stamm-CA signiert einige Zwischen-CAs, die dann die endgültigen Zertifikate ausstellen.

Diese flache hierarchische Struktur erhöht die Transparenz, vereinfacht die Prozesse zum Sperren von Zertifikaten und verringert die Wahrscheinlichkeit von Fehlkonfigurationen. CA Service ist zwar ein regionaler Dienst, aber eine Stamm-CA in einer Region kann untergeordnete CAs in anderen Regionen signieren.

Halten Sie sich in Ihrer CA-Diensthierarchie an die folgenden Best Practices, wie im Diagramm dargestellt:

Isolieren Sie Ihre Root-CA in einem eigenen Google Cloud Projekt, um die ausstellende CA zu signieren.
Erstellen Sie ausstellende CAs in CA-Pools, die in separaten Projekten gehostet werden. Hosten Sie diese Pools in separaten Projekten und segmentieren Sie sie nach geografischem Standort (Region), Softwareentwicklungszyklus (Entwicklung, Produktion, Test) oder einem bestimmten Anwendungsfall.
Konfigurieren Sie Certificate Manager so, dass ein ausstellender CA-Pool verwendet wird, der privat vertrauenswürdige Zertifikate für unterstützte Ressourcen ausstellen kann.

Empfohlenes Design der Zertifizierungsstellenhierarchie. — Empfohlenes Design für Ihre Zertifizierungsstellenhierarchie (zum Vergrößern klicken)

Umfassende Hostnamenabdeckung

Wir empfehlen, dass Ihre Zertifikate eine ausreichende Hostnamenabdeckung für alle Domains und Subdomains bieten, die Ihre Dienste schützen müssen. Eine unzureichende Hostnamenabdeckung kann zu Sicherheitswarnungen für Nutzer, Dienstunterbrechungen und einer negativen Nutzererfahrung führen.

Verwenden Sie möglichst nicht für mehrere Domains nur ein einziges Zertifikat. Wenn das einzelne Zertifikat nicht verlängert wird oder versehentlich gelöscht wird, sind alle Domains, die es abdeckt, nicht mehr gesichert. Wir empfehlen, separate Zertifikate für verschiedene Domains zu erstellen.

Wenn Sie später neue Subdomains oder Dienste hinzufügen möchten, verwenden Sie von Anfang an Platzhalterzeichen, um die Subdomains oder Dienste in Ihr Zertifikat aufzunehmen. Ein Wildcard-Zertifikat für *.myorg.example.com sichert beispielsweise nur die erste Subdomainebene, nicht aber die tieferen Subdomainebenen wie sub.subdomain.myorg.example.com.

Von Google verwaltete Zertifikate verwenden

Für eine effiziente Verwaltung öffentlicher Zertifikate und eine einfache Verwendung empfehlen wir die Verwendung von von Google verwalteten Zertifikaten. Dieser Ansatz reduziert den betrieblichen Aufwand erheblich, da Aufgaben wie die Zertifikatsrotation automatisiert werden und die mit manuellen Verlängerungen verbundenen Risiken entfallen.

Außerdem lassen sich von Google verwaltete Zertifikate nahtlos in andereGoogle Cloud -Dienste einbinden. Von Google verwaltete Zertifikate sind 90 Tage lang gültig. Der Verlängerungsprozess beginnt etwa einen Monat vor Ablauf.

Zertifikatsleistung skalieren und verbessern

In den folgenden Abschnitten werden die Best Practices zum Skalieren Ihrer Zertifikate und zur Verbesserung der Leistung von zertifikatsbezogenen Aktionen wie Bereitstellung und Erneuerung beschrieben.

Dezentrale Bereitstellung für Certificate Manager anwenden

Verwenden Sie Certificate Manager pro Projekt und Standort. Das bedeutet, dass Ihre Zertifikate im selben Projekt wie die zugehörigen Ressourcen in derselben Region gespeichert werden. Diese Strategie erhöht die Zuverlässigkeit, da die Wiederverwendung von Zertifikaten in verschiedenen Regionen verhindert wird. So werden die Auswirkungen im unwahrscheinlichen Fall eines regionalen Ausfalls minimiert.

Da Kontingente und Limits auf Google Cloud Projektebene angewendet werden, erhöht die Bereitstellung von Certificate Manager in mehreren Projekten Ihre Gesamtkontingente. Die Nutzung einer Ressource in einem Projekt hat keinen Einfluss auf das verfügbare Kontingent in einem anderen Projekt.

Zertifikate mit ECDSA-Schlüsseln verwenden

In diesem Abschnitt wird erläutert, warum wir ECDSA als Best Practice für Zertifikatsignaturschlüssel gegenüber RSA empfehlen.

Welcher Schlüsseltyp soll verwendet werden?

ECDSA P-256 ist der empfohlene Schlüsseltyp für die meisten TLS-Zertifikate, da er eine hohe kryptografische Sicherheit, eine hervorragende Leistung bei Signiervorgängen und eine effiziente Nutzung der Netzwerkbandbreite bietet.

Hier sind einige mögliche Gründe für die Verwendung anderer Zertifikatschlüsseltypen:

Wenn Sie Legacy-Clients unterstützen müssen, die keine ECDSA-Zertifikate unterstützen, können Sie zusätzlich zu ECDSA P-256-Zertifikaten auch RSA-2048-Zertifikate bereitstellen.
Wenn Sie bestimmte Compliance-Anforderungen haben, die die Verwendung größerer Schlüsselgrößen oder bestimmter Schlüsseltypen erfordern, können Sie ECDSA P-384-, RSA-2048-, RSA-3072- und RSA-4096-Schlüssel verwenden.

Warum ECDSA gegenüber RSA wählen?

Der Hauptvorteil von ECDSA liegt darin, dass es ein gleichwertiges kryptografisches Sicherheitsniveau mit deutlich kleineren Schlüsseln als RSA bietet. Diese Effizienz führt zu spürbaren Leistungs- und Ressourcenvorteilen. Ein kleinerer Schlüssel bedeutet nicht, dass die Sicherheit geringer ist. ECDSA basiert auf dem Problem des diskreten Logarithmus auf elliptischen Kurven, das pro Einheit des Schlüssels eine höhere Sicherheit und in einigen Fällen eine bessere Recheneffizienz im Vergleich zu RSA bietet.

Beispiel:

Ein 256-Bit-ECDSA-Schlüssel bietet ein ähnliches Sicherheitsniveau wie ein RSA-3072-Schlüssel.
Ein 384-Bit-ECDSA-Schlüssel bietet ein höheres Sicherheitsniveau als jede weitgehend unterstützte RSA-Schlüsselgröße.

Wichtige Vorteile von ECDSA:

Leistung: ECDSA-Signierungsvorgänge sind deutlich weniger rechenintensiv als RSA-Vorgänge mit einem gleichwertigen Sicherheitsniveau. Dadurch werden CPU-Last und Latenz reduziert, was für Systeme mit hohem Durchsatz oder latenzsensible Systeme entscheidend ist.
Effizienz: Kleinere Schlüssel und Signaturen erfordern weniger Bandbreite und Speicherplatz, was besonders in ressourcenbeschränkten Umgebungen wie Mobil- und IoT-Geräten von Vorteil ist.

Sie können die folgende benutzerdefinierte Organisationsrichtlinie erstellen, um die Verwendung bestimmter Schlüsseltypen in Ihren Zertifikaten zu erzwingen. Dies gilt nur für von Google verwaltete Zertifikate aus dem CA Service (von Private Trust verwaltete Zertifikate), nicht für selbstverwaltete Zertifikate und von Google verwaltete Zertifikate mit öffentlichem Vertrauen.

    name: organizations/ORGANIZATION_ID/customConstraints/custom.restrictAlgorithm \
    resourceTypes: \
    - certificatemanager.googleapis.com/CertificateIssuanceConfig \
    methodTypes: \
    - CREATE \
    - UPDATE \
    condition: "resource.keyAlgorithm == 'ECDSA_P256'" \
    actionType: ALLOW \
    displayName: Allow only ECDSA_P256 in Certificate Issuance configs \
    description: Only ECDSA_P256 certificates are allowed from CA Service.

CA-Pool zum Ausstellen von Zertifikaten von privaten CAs verwenden

Wir empfehlen, CA-Pools für Ihre ausstellenden Zertifizierungsstellen zu verwenden. Ein Zertifizierungsstellenpool ist eine Sammlung mehrerer Zertifizierungsstellen mit einer gemeinsamen Richtlinie für das Ausstellen von Zertifikaten sowie einer IAM-Richtlinie (Identity and Access Management). Durch die Verwendung eines CA-Pools wird die Gesamtzahl der effektiven Abfragen pro Sekunde erhöht, da die eingehenden Zertifikatsanfragen per Load-Balancing auf alle aktivierten CAs im Pool verteilt werden. Dies verbessert die Leistung, ohne dass sich dies auf die Arbeitslast oder clientseitige Änderungen auswirkt.

CA-Pools bieten einen einzelnen Endpunkt für die Ausstellung und den Abruf von Zertifikaten. Mit CA-Pools können Sie Ihre CAs sicher rotieren, ohne dass es aufgrund von Zertifikatsablauf oder Kompromittierung zu Ausfallzeiten kommt.

Zertifikatszuordnungen verwenden

Für eine optimale Skalierbarkeit empfehlen wir, Zertifikatszuordnungen mit unterstützten Ressourcen zu verwenden. Zertifikatszuordnungen sind so konzipiert, dass sie skaliert werden können. Sie unterstützen standardmäßig Tausende von Zertifikateinträgen und können Millionen von Zertifikaten verarbeiten. Wenn sie von Load-Balancern verwendet werden, haben Zertifikatszuordnungseinträge Vorrang vor anderen Zertifikaten, z. B. Compute Engine-SSL-Zertifikaten.

Mit Zertifikatszuordnungen können Sie auch die Logik für die Zertifikatsauswahl konfigurieren. Wenn beispielsweise während eines Handshake der Hostname eines Clients mit keinem Eintrag in der bereitgestellten Zertifikatszuordnung übereinstimmt, gibt der Load Balancer das primäre Zertifikat zurück.

Den richtigen Domainautorisierungstyp auswählen

Um von Google verwaltete Zertifikate auszustellen, können Sie die Inhaberschaft Ihrer Domain entweder über die Load-Balancer-Autorisierung oder die DNS-Autorisierung bestätigen.

In der folgenden Tabelle werden die Überlegungen für die einzelnen Ansätze beschrieben:

Funktion	Load-Balancer-Autorisierung	DNS-Autorisierung
Einrichtungskomplexität	Es sind keine zusätzlichen Konfigurationsschritte oder Änderungen an Ihrer DNS-Konfiguration erforderlich.	Sie müssen eine DNS-Autorisierung erstellen und den entsprechenden CNAME-Eintrag Ihrer DNS-Konfiguration hinzufügen.
Netzwerksicherheit	Der Load Balancer muss über das Internet auf Port `443` vollständig zugänglich sein, einschließlich der DNS-Konfiguration für alle Domains, die von einem Zertifikat bereitgestellt werden. Die Load-Balancer-Autorisierung funktioniert nicht mit anderen Konfigurationen.	Die DNS-Autorisierung funktioniert auch bei sehr komplexen Konfigurationen, z. B. bei Ports, die nicht 443 sind, und bei CDN-Layern vor dem Zielproxy.
Bereitstellungsgeschwindigkeit	Schnellere Bereitstellung. Sie können Zertifikate erst bereitstellen, wenn der Load-Balancer vollständig eingerichtet ist und Netzwerk-Traffic verarbeitet.	Sie können Zertifikate im Voraus bereitstellen, bevor der Zielproxy bereit ist, Netzwerk-Traffic zu verarbeiten.
Platzhalterzertifikate	Nicht unterstützt.	Unterstützt.

Rotation von selbstverwalteten Zertifikaten automatisieren

Im Gegensatz zu von Google verwalteten Zertifikaten müssen selbstverwaltete Zertifikate manuell ersetzt werden, bevor sie ablaufen. Wir empfehlen, diesen Prozess mit den CLM-Angeboten (Certificate Lifecycle Management) Ihrer Wahl zu automatisieren. So lassen sich Fehler und Ausfallzeiten reduzieren und die betriebliche Effizienz steigern.

Sie können auch Zertifikatszuordnungen verwenden, um eine nahtlose Zertifikatsrotation zu orchestrieren. Dieser Prozess umfasst die folgenden Schritte:

Überwachen Sie das Ablaufdatum von Zertifikaten mit Cloud Monitoring und Benachrichtigungen. Wir empfehlen, eine Benachrichtigung für Zertifikate zu erstellen, die in den nächsten 15 bis 30 Tagen ablaufen.
Generieren Sie eine Anfrage für die Signierung des Zertifikats (Certificate Signing Request, CSR) und einen privaten Schlüssel, die Sie an Ihre Zertifizierungsstelle senden.
Senden Sie Ihren CSR und privaten Schlüssel an Ihre CA und rufen Sie dann das neue Zertifikat ab.
Laden Sie das neue Zertifikat in den Zertifikatmanager in eine geeignete Zertifikatszuordnung hoch.
- Wenn die Domainnamen im neuen Zertifikat mit einem bald ablaufenden Zertifikat übereinstimmen, verwenden Sie die UpdateCertificate-Methode für die vorhandene Zertifikatsressource.
- Wenn das neue Zertifikat andere Domainnamen hat, verwenden Sie zuerst die CreateCertificateRequest-Methode mit den neuen PEM-Dateien (Privacy-Enhanced Mail), um es zu erstellen. Verwenden Sie dann die UpdateCertificateMapEntry-Methode, um den Verweis des alten Zertifikats in der Zertifikatszuordnung durch den neuen zu ersetzen.
Wichtig: Sie müssen diesen Vorgang in einem API-Aufruf ohne Ausfallzeiten durchführen.

Angemessene Zugriffssteuerungen anwenden

Wir empfehlen, bei der Konfiguration Ihrer Zugriffssteuerungen die Prinzipien der geringsten Berechtigung und der Trennung von Aufgaben zu berücksichtigen. In den folgenden Abschnitten werden diese Empfehlungen näher erläutert.

Prinzip der geringsten Berechtigung anwenden

Berücksichtigen Sie beim Zuweisen von Berechtigungen zum Verwalten von Zertifikaten das Prinzip der geringsten Berechtigung und gewähren Sie die Mindestberechtigungen, die zum Ausführen einer Aufgabe erforderlich sind. Wir raten dringend davon ab, einfache IAM-Rollen zu verwenden. Weisen Sie stattdessen vordefinierte oder benutzerdefinierte Certificate Manager- und CA Service-Rollen zu, um das Risiko von Sicherheitsvorfällen im Zusammenhang mit übermäßigen Berechtigungen zu minimieren.

Aufgabentrennung planen

Wir empfehlen, separate Identitäten und Berechtigungen für Zertifikatsadministratoren und Nutzer mit der Rolle „Zertifikataussteller“ oder „Zertifikatsanforderer“ zu verwenden. Erstellen Sie dazu separate Administrator- und Anfragestellergruppen oben in der Ressourcenhierarchie für Ihre Nutzer.

Achten Sie darauf, dass Ihre Administratorgruppe für die folgenden Aktionen verantwortlich ist:

Verwalten und pflegen Sie Ihre Zertifikatsinfrastruktur, z. B. die CA-Bereitstellung.
Zertifikatsvorlagen konfigurieren
Verwalten Sie Ihre Zertifikatssperrliste (Certificate Revocation List, CRL) und OCSP-Responder (Online Certificate Status Protocol).
Sicherheitsrichtlinien für Ihre Zertifizierungsstelle implementieren.

Weisen Sie für Projekte, die eine Stammzertifizierungsstelle hosten, keinen Nutzern oder Gruppen einfache Rollen wie „Inhaber“ (roles/owner), „Bearbeiter“ (roles/editor) und „CA Service Admin“ (roles/privateca.admin) zu. So werden versehentliches Löschen, Fehlkonfigurationen und eine zu hohe Anzahl von Impressionen verhindert. Verwenden Sie stattdessen Privileged Access Manager (PAM) für den Just-in-Time-Zugriff (JIT) nach Bedarf mit Begründung und Genehmigungen, nachdem die Root-Zertifizierungsstelle installiert und konfiguriert wurde.

Die Gruppe, die die Anfrage stellt, muss für die täglichen Abläufe der Verarbeitung von Zertifikatsanfragen und der Ausstellung von Zertifikaten auf der Grundlage vordefinierter Vorlagen verantwortlich sein.

In der folgenden Tabelle sind die IAM-Rollen aufgeführt, die in der Regel mit verschiedenen Jobfunktionen verknüpft sind:

Persona	Beschreibung	IAM-Rollen
Zertifikatadministratoren	CA- und Zertifikatinfrastruktur einrichten und verwalten	Zertifikatmanager-Inhaber (`roles/certificatemanager.owner`), CA Service-Administrator (`roles/privateca.admin`)
Zertifikatanforderer	Zertifikate für Arbeitslasten anfordern.	Anforderer von Zertifikaten für CA-Dienste (`roles/privateca.certificateRequester`)
Arbeitslasten (Automatisierungsdienstkonten)	Wird von Arbeitslasten oder in Pipelines zum Anfordern von Zertifikaten verwendet.	Anfragesteller des CA Service-Arbeitslastzertifikats (`roles/privateca.workloadCertificateRequester`)
Sicherheitsingenieure oder PKI-Inhaber	Zertifikatsrichtlinie, ‑sperrung und ‑lebenszyklus verwalten	Operation Manager für CA Service (`roles/privateca.caManager`), Zertifikatverwalter für Certificate Authority Service (`roles/privateca.certificateManager`)
DevOps- oder Plattformentwickler	Bereitstellung von Zertifikaten auf Load-Balancern verwalten und mehr.	Zertifikatmanager-Bearbeiter (`roles/certificatemanager.editor`)
Prüfer oder Compliance	Zertifikate und ihre Verwendung überwachen.	Zertifikatmanager-Betrachter (`roles/certificatemanager.viewer`), Certificate Authority Service-Auditor (`roles/privateca.auditor`)

DNS-Autorisierung pro Projekt für Multi-Region- und Multi-Cloud-Bereitstellungen verwenden

Wir empfehlen, die DNS-Autorisierung pro Projekt zu verwenden, um mehrere Autorisierungen für Projekte in mehreren Regionen, mehreren Clouds und im gesamten Software-Entwicklungslebenszyklus (SDLC) unabhängig voneinander zu verwalten.

Durch die Aufteilung von DNS-Autorisierungen wird sichergestellt, dass jedes Projekt seine eigenen DNS-Einträge und Berechtigungen hat. Mit dieser Steuerungsebene kann jedes Projekt seine DNS-Konfigurationen autonom verwalten, ohne dass die Vorgänge anderer Projekte beeinträchtigt werden oder sich auf sie auswirken. So kann ein Entwicklungsteam beispielsweise neue DNS-Konfigurationen für seine spezifische Anwendung testen, ohne dass dies negative Auswirkungen auf die Produktionssysteme oder andere laufende Projekte hat.

CAA-Einträge zum Schutz Ihrer Domains verwenden

CAA-Einträge (Certification Authority Authorization) sind ein Sicherheitsmechanismus im Domain Name System (DNS). Mit CAA-Einträgen können Domaininhaber die öffentlichen Zertifizierungsstellen (Certification Authorities, CAs) konfigurieren, die Zertifikate für ihre Domains ausstellen dürfen. Diese Kontrolle ist wichtig, um die unbefugte Ausstellung von Zertifikaten zu verhindern. Durch CAA wird die Angriffsfläche für betrügerische Zertifikate verringert, wodurch Websites sicherer werden.

Bei von Google verwalteten Zertifikaten empfehlen wir, die folgenden manuell zu autorisieren, um die Zuverlässigkeit Ihrer Anfragen zum Ausstellen und Erneuern von Zertifikaten zu optimieren:

Cloud Logging, Cloud Monitoring und Sichtbarkeit

In den folgenden Abschnitten werden die Best Practices für die Audit-Protokollierung und für die Überwachung der Zertifikatsnutzung und des Zertifikatsablaufs beschrieben.

Audit-Logging aktivieren und zusammenfassen

Wenn Sie alle Ressourcen Ihrer Organisation überwachen möchten, fassen Sie die Audit-Logs zur Administratoraktivität für alle Dienste, einschließlich Certificate Manager, an einem zentralen Ort zusammen.

So kann Ihr Sicherheitsteam oder Prüfer alle Aktivitäten im Zusammenhang mit dem Erstellen oder Ändern von Certificate Manager- und CA Service-Ressourcen an einem Ort überprüfen. Weitere Informationen zum Konfigurieren zusammengefasster Logs finden Sie unter Logs Ihrer Organisation zusammenfassen und speichern.

Zertifikatsnutzung und ‑ablauf überwachen

Wir empfehlen, logbasierte Benachrichtigungen für wichtige Certificate Manager-Ereignisse einzurichten, z. B. für die Verwendung der Stamm-CA, den Ablauf von Zertifikaten und das Löschen von Zertifikaten. Diese Benachrichtigungen helfen Ihnen, Vorgänge zu priorisieren, z. B. eine hohe Anzahl von Fehlern beim Erstellen von Zertifikaten, und können einen Downstream-Prozess auslösen, um entweder ein neues Zertifikat anzufordern oder das Kontingent zu erhöhen.

Konfigurieren Sie die folgenden Log-Benachrichtigungen und ‑Richtlinien für privilegierte Vorgänge:

Compliance-Anforderungen

In der Regel werden in Compliance-Frameworks allgemeine Erwartungen und Ziele für die Zertifikatsverwaltung festgelegt, nicht für bestimmte Produkte oder Konfigurationen.

Beispielsweise erfordern der Payment Card Industry Data Security Standard (PCI DSS) und das National Institute of Standards and Technology (NIST), dass Organisationen Rotationszeiträume für Signierschlüssel dokumentieren und implementieren. Sie schreiben auch die kontinuierliche Überwachung des Inventars und aller vertrauenswürdigen Signaturschlüssel und Zertifikate vor, die Karteninhaberdaten schützen.

Weitere Informationen dazu, wie Google Cloud -Dienste dazu beitragen können, die Anforderungen verschiedener Compliance-Frameworks zu erfüllen, finden Sie in den folgenden Ressourcen: