Google verwendet KI-Technologie, um Inhalte in Ihre bevorzugte Sprache zu übersetzen. KI-Übersetzungen können Fehler enthalten.

Best Practices für Certificate Manager

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

Bevor Sie diese Seite lesen, sollten Sie sich mit den Übersichtsseiten zu Zertifikatmanager und dem Certificate Authority Service vertraut machen.

Architektur für die Zertifikatsverwaltung entwerfen

Beim Entwerfen einer Strategie für die Zertifikatsverwaltung in Unternehmen müssen Sie die wichtigsten Anwendungsfälle Ihres Unternehmens 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 jede Designoption erläutert.

Zertifikatstyp auswählen

Beim Erstellen eines Zertifikats müssen Sie einen Zertifikatstyp auswählen, der je nach Anwendungsfall, Anwendungsanforderungen und Sicherheitsrichtlinien Ihres Unternehmens geeignet ist.

Im folgenden Flussdiagramm können Sie analysieren, welcher Zertifikatstyp für Sie am besten geeignet ist:

Beurteilen, welcher Zertifikatstyp ausgewählt werden soll. — Zertifikatstyp auswählen (zum Vergrößern klicken)

Hier sind einige hilfreiche Links zur Dokumentation für die im Flussdiagramm genannten Themen:

Hierarchie des privaten CA Service optimieren

Wir empfehlen, die Hierarchie Ihres CA Service so einfach wie möglich zu halten, um einen reibungslosen Betrieb und die Fehlerbehebung zu gewährleisten. Sie müssen Ihre Root-Zertifizierungsstelle (CA) in einem eigenen Google-Projekt speichern. Die Root-CA signiert einige Intermediate-CAs, die dann die endgültigen Zertifikate ausstellen.

Diese flache hierarchische Struktur verbessert die Transparenz, vereinfacht die Prozesse zur Zertifikatsperrung und verringert die Wahrscheinlichkeit von Fehlkonfigurationen. Obwohl CA Service ein regionaler Dienst ist, kann eine Root-CA in einer Region untergeordnete CAs signieren, die sich in anderen Regionen befinden.

Beachten Sie in Ihrer CA Service-Hierarchie 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), Lebenszyklus der Softwareentwicklung (Entwicklung, Produktion, Test) oder einem bestimmten Anwendungsfall.
Konfigurieren Sie Zertifikatmanager so, dass ein ausstellender CA-Pool verwendet wird, der privat vertrauenswürdige Zertifikate für unterstützte Ressourcen ausstellen kann.

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

Umfassende Hostnamenabdeckung verwenden

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 nicht ein einzelnes Zertifikat für mehrere Domains. Wenn das einzelne Zertifikat nicht verlängert wird oder versehentlich gelöscht wird, sind alle Domains, die es abdeckt, nicht mehr geschützt. Wir empfehlen, für verschiedene Domains unterschiedliche Zertifikate zu erstellen.

Wenn Sie später neue Subdomains oder Dienste hinzufügen möchten, verwenden Sie Platzhalterzeichen, um die Subdomains oder Dienste von Anfang an in Ihr Zertifikat aufzunehmen. Ein Platzhalterzertifikat für *.myorg.example.com schützt 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 Betriebsaufwand erheblich, automatisiert Aufgaben wie die Zertifikatsrotation und beseitigt die Risiken, die mit manuellen Verlängerungen verbunden sind.

Darüber hinaus bieten von Google verwaltete Zertifikate eine nahtlose Integration mit anderen Google Cloud Diensten. Zertifikatmanager unterstützt nur die Public Certificate Authority (pki.goog) und die Let's Encrypt CA (letsencrypt.org) für die Ausstellung öffentlich vertrauenswürdiger von Google verwalteter Zertifikate. Zertifikatmanager stellt von Google verwaltete Zertifikate mit einer Gültigkeitsdauer von 45 oder 90 Tagen bereit, je nach ausstellender CA:

Die Gültigkeitsdauer von Zertifikaten, die von der Public CA ausgestellt wurden, wird schrittweise von 90 auf 45 Tage umgestellt. Vorhandene Zertifikate mit einer Gültigkeitsdauer von 90 Tagen bleiben bis zur nächsten Verlängerung 90 Tage lang gültig.
Zertifikate, die von der Let's Encrypt CA ausgestellt wurden, haben eine Gültigkeitsdauer von 90 Tagen.

Zertifikatmanager startet den Verlängerungsprozess automatisch, wenn etwa ein Drittel der Gültigkeitsdauer des Zertifikats verbleibt. Die Verlängerung beginnt etwa 15 Tage vor Ablauf für Zertifikate mit einer Gültigkeitsdauer von 45 Tagen und etwa 30 Tage vor Ablauf für Zertifikate mit einer Gültigkeitsdauer von 90 Tagen.

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 Verlängerung beschrieben.

Dezentrale Bereitstellung für Zertifikatmanager anwenden

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

Da Kontingente und Limits auf Google Cloud Projektebene angewendet werden, erhöht die Bereitstellung von Zertifikatmanager 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 sollte verwendet werden?

ECDSA P-256 ist die empfohlene Wahl des Schlüsseltyps für die meisten TLS-Zertifikate, da ECDSA P-256 eine hohe kryptografische Sicherheit, eine hervorragende Leistung für Signaturvorgänge und eine effiziente Nutzung der Netzwerkbandbreite bietet.

Einige der möglichen Gründe für die Verwendung anderer Zertifikatschlüsseltypen sind:

Wenn Sie ältere 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 im Vergleich zu RSA bietet. Diese Effizienz führt zu spürbaren Leistungs- und Ressourcenvorteilen. Ein kleinerer Schlüssel bedeutet nicht weniger Sicherheit. ECDSA basiert auf dem Problem des diskreten Logarithmus auf elliptischen Kurven, das eine höhere Sicherheit pro Schlüsseleinheit 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 weit verbreitete RSA-Schlüsselgröße.

Wichtige Vorteile von ECDSA:

Leistung: ECDSA-Signaturvorgänge sind deutlich weniger rechenintensiv als RSA-Vorgänge mit einem gleichwertigen Sicherheits niveau. Dadurch werden die CPU-Last und die Latenz reduziert, was für Systeme mit hohem Durchsatz oder latenzempfindliche Systeme entscheidend ist.
Effizienz: Kleinere Schlüssel und Signaturen erfordern weniger Bandbreite und Speicherplatz, was besonders für ressourcenbeschränkte Umgebungen wie Mobilgeräte und IoT-Geräte 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 von CA Service (privat verwaltete Zertifikate), nicht für selbstverwaltete Zertifikate und öffentlich vertrauenswürdige von Google verwaltete Zertifikate.

    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 CAs zu verwenden. Ein CA-Pool ist eine Sammlung mehrerer CAs 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 Anzahl der effektiven Abfragen pro Sekunde durch Load-Balancing erhöht und die eingehenden Zertifikatsanfragen werden auf alle aktivierten CAs im Pool verteilt. Dadurch wird die Leistung verbessert, ohne dass sich dies auf die Arbeitslast oder clientseitige Änderungen auswirkt.

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

Zertifikatszuordnungen verwenden

Um eine optimale Skalierbarkeit zu gewährleisten, empfehlen wir die Verwendung von Zertifikatszuordnungen mit unterstützten Ressourcen. Zertifikatszuordnungen sind so konzipiert, dass sie skaliert werden können. Sie unterstützen standardmäßig Tausende von Zertifikatseinträ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 Handshakes der Hostname eines Clients nicht mit einem Eintrag in der bereitgestellten Zertifikatszuordnung übereinstimmt, gibt der Load-Balancer das primäre Zertifikat zurück.

Richtigen Typ der Domainautorisierung auswählen

Um von Google verwaltete Zertifikate auszustellen, können Sie Ihr Domaininhaberschaft entweder mit der Load-Balancer-Autorisierung oder der DNS-Autorisierung nachweisen.

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

Funktion	Load-Balancer-Autorisierung	DNS-Autorisierung
Komplexität der Einrichtung	Erfordert keine zusätzlichen Konfigurationsschritte oder Änderungen an Ihrer DNS-Konfiguration.	Erfordert, dass Sie eine DNS-Autorisierung erstellen und den entsprechenden CNAME-Eintrag zu 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 mit sehr komplexen Konfigurationen, z. B. mit anderen Ports als 443 und CDN-Ebenen vor dem Ziel-Proxy.
Bereitstellungsgeschwindigkeit	Schnellere Bereitstellung. Sie können Zertifikate erst bereitstellen, nachdem der Load-Balancer vollständig eingerichtet ist und Netzwerkverkehr bereitstellt.	Sie können Zertifikate im Voraus bereitstellen, bevor der Ziel-Proxy bereit ist, Netzwerkverkehr bereitzustellen.
Platzhalterzertifikate	Nicht unterstützt.	Unterstützt.

Rotation selbstverwalteter Zertifikate automatisieren

Im Gegensatz zu von Google verwalteten Zertifikaten müssen selbstverwaltete Zertifikate manuell ersetzt werden, bevor sie ablaufen. Wir empfehlen, diesen Prozess mithilfe der CLM-Angebote (Certificate Lifecycle Management) Ihrer Wahl zu automatisieren. So können Sie 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 den Ablauf 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 Zertifikatsignierungsanfrage (Certificate Signing Request, CSR) und einen privaten Schlüssel, die Sie an Ihre CA senden.
Senden Sie Ihre CSR und Ihren privaten Schlüssel an Ihre CA und rufen Sie dann das neue Zertifikat ab.
Laden Sie das neue Zertifikat in Certificate Manager in eine geeignete Zertifikatszuordnung hoch.
- Wenn die Domainnamen im neuen Zertifikat mit einem Zertifikat übereinstimmen, das bald abläuft, verwenden Sie die UpdateCertificate Methode für die vorhandene Zertifikatsressource.
- Wenn das neue Zertifikat andere Domainnamen hat, erstellen Sie es zuerst mit der CreateCertificateRequest Methode und den neuen PEM-Dateien (Privacy-Enhanced Mail) 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 Prozess in einem API-Aufruf abschließen, ohne dass es zu Ausfallzeiten kommt.

Geeignete Zugriffssteuerungen anwenden

Wir empfehlen, beim Konfigurieren Ihrer Zugriffssteuerungen die Prinzipien der geringsten Berechtigung und der Aufgabentrennung zu berücksichtigen. In den folgenden Abschnitten werden diese Empfehlungen näher erläutert.

Prinzip der geringsten Berechtigung anwenden

Verwenden 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 empfehlen dringend, keine einfachen IAM-Rollen zu verwenden. Gewähren Sie stattdessen vordefinierte oder benutzerdefinierte Rollen für Zertifikatmanager und CA Service, um das Risiko von Sicherheitsvorfällen im Zusammenhang mit übermäßigen Berechtigungen zu minimieren.

Aufgabentrennung planen

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

Die Gruppe der Administratoren muss für die folgenden Aktionen verantwortlich sein:

Verwalten und Warten Ihrer Zertifikatsinfrastruktur, z. B. CA-Bereitstellung.
Zertifikatvorlagen konfigurieren.
Verwalten Sie Ihre Zertifikatssperrliste (Certificate Revocation List, CRL) und die OCSP-Responder (Online Certificate Status Protocol).
Implementieren Sie Sicherheitsrichtlinien für Ihre CA.

Weisen Sie für Projekte, die eine Root-CA hosten, keinen Nutzern oder Gruppen einfache Rollen wie „Inhaber“ (roles/owner), „Bearbeiter“ (roles/editor) und „CA Service-Administrator“ (roles/privateca.admin) zu. So werden versehentliches Löschen, Fehlkonfigurationen und übermäßige Offenlegung 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-CA installiert und konfiguriert wurde.

Die Anforderergruppe ist für die täglichen Vorgänge der Verarbeitung von Zertifikatsanfragen und der Ausstellung von Zertifikaten auf der Grundlage vordefinierter Vorlagen verantwortlich.

In der folgenden Tabelle sind die IAM-Rollen aufgeführt, die typischerweise mit verschiedenen Jobfunktionen verbunden sind:

Persona	Beschreibung	IAM-Rollen
Zertifikatsadministratoren	Richten Sie die CA- und Zertifikatsinfrastruktur ein und verwalten Sie sie.	Zertifikatmanager-Inhaber (`roles/certificatemanager.owner`), CA Service-Administrator (`roles/privateca.admin`)
Zertifikatsanforderer	Zertifikate für Arbeitslasten anfordern.	Anfragesteller des Certificate Authority Service-Zertifikats (`roles/privateca.certificateRequester`)
Arbeitslasten (Dienstkonten für die Automatisierung)	Werden von Arbeitslasten oder in Pipelines verwendet, um Zertifikate anzufordern.	Anfragesteller des Certificate Authority Service-Arbeitslastzertifikats (`roles/privateca.workloadCertificateRequester`)
Sicherheitsingenieure oder PKI-Inhaber	Zertifikatsrichtlinie, Sperrung und Lebenszyklus verwalten.	CA Service-Betriebsmanager (`roles/privateca.caManager`), Zertifikatmanager 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`)
Auditor oder Compliance-Beauftragter	Zertifikate und ihre Verwendung überwachen.	Zertifikatmanager-Betrachter (`roles/certificatemanager.viewer`), Auditor für Certificate Authority Service (`roles/privateca.auditor`)

DNS-Autorisierung pro Projekt für Bereitstellungen in mehreren Regionen und Clouds verwenden

Wir empfehlen, den Ansatz der DNS-Autorisierung pro Projekt zu verwenden, um mehrere Autorisierungen für Projekte in mehreren Regionen, mehreren Clouds und im gesamten Lebenszyklus der Softwareentwicklung (SDLC) unabhängig zu verwalten.

Durch die Unterteilung von DNS-Autorisierungen wird sichergestellt, dass jedes Projekt einen eigenen Satz von DNS-Einträgen und -Berechtigungen hat. Mit dieser Kontrolle kann jedes Projekt seine DNS-Konfigurationen autonom verwalten, ohne die Vorgänge anderer Projekte zu beeinträchtigen oder von ihnen beeinflusst zu werden. Ein Entwicklungsteam kann beispielsweise mit neuen DNS-Konfigurationen für seine spezifische Anwendung experimentieren, ohne dass dies 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 DNS (Domain Name System). CAA-Einträge bieten Domaininhabern die vollständige Kontrolle über die Konfiguration der öffentlichen Zertifizierungsstellen (CAs), die Zertifikate für ihre Domains ausstellen können. Diese Kontrolle ist wichtig, um die unbefugte Ausstellung von Zertifikaten zu verhindern. Mit CAA wird die Angriffsfläche für betrügerische Zertifikate verringert und Websites werden effektiver geschützt.

Für von Google verwaltete Zertifikate empfehlen wir, die folgenden manuell zu autorisieren, um die Zuverlässigkeit Ihrer Zertifikatsausstellungs- und Verlängerungsanfragen zu optimieren:

Cloud Logging, Cloud Monitoring und Sichtbarkeit

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

Audit-Logging aktivieren und aggregieren

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

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

Zertifikatsnutzung und -ablauf überwachen

Wir empfehlen, logbasierte Benachrichtigungen für wichtige Zertifikatmanager-Ereignisse einzurichten, z. B. für die Nutzung der Root-CA, den Ablauf von Zertifikaten und das Löschen von Zertifikaten. Mit diesen Benachrichtigungen können Sie Vorgänge wie eine hohe Anzahl von Fehlern bei der Zertifikatserstellung priorisieren und einen nachgelagerten Prozess auslösen, um entweder ein neues Zertifikat anzufordern oder das Kontingent zu erhöhen.

Konfigurieren Sie die folgenden Logbenachrichtigungen und -richtlinien für Vorgänge im Zusammenhang mit Berechtigungen:

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.

Der Payment Card Industry Data Security Standard (PCI DSS) und das National Institute of Standards and Technology (NIST) fordern beispielsweise von Unternehmen, Rotationszeiträume für Signaturschlüssel zu dokumentieren und zu implementieren. Außerdem ist die kontinuierliche Überwachung des Inventars und aller vertrauenswürdigen Signaturschlüssel und -zertifikate vorgeschrieben, die Karteninhaberdaten schützen.

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