PKI ( Public Key Infrastructure ) ist ein System aus Rollen, Verfahren und Richtlinien, das für die Erstellung, Verteilung, Verwaltung, Nutzung und den Widerruf digitaler Zertifikate sowie für die Verwaltung der Public-Key-Verschlüsselung erforderlich ist. PKI dient der Identitätsprüfung von Nutzern durch die Zuweisung eines privaten Schlüssels. Sie ist ein vertrauenswürdiger Dienst, der sicherstellt, dass Sender und Empfänger von Daten tatsächlich die Person sind, für die sie sich ausgeben.

PKI basiert auf Komponenten und Verfahren zur Verwaltung der Schlüsselpaare (öffentliche und private Schlüsselpaare).

Eine typische PKI besteht aus den folgenden Komponenten:

Zertifizierungsstelle (CA): Ein vertrauenswürdiger CA ist die einzige Entität in PKI, die vertrauenswürdige digitale Zertifikate ausstellen kann. CA nimmt Zertifikatsanfragen entgegen und überprüft die von den Antragstellern bereitgestellten Informationen basierend auf Zertifikatsverwaltung Die CA signiert die Zertifikate mit ihrem privaten Schlüssel und stellt sie den Antragstellern aus, wenn die Informationen legal sind.
Registrierungsstelle (RA): RA ist für den Empfang von Zertifikatsignaturanfragen für die Erstregistrierung oder Erneuerung von Zertifikaten von Benutzern, Servern und anderen Anwendungen verantwortlich. RA überprüft die Identität einer Endeinheit und leitet die Anfrage an eine Zertifizierungsstelle (CA) weiter.
Öffentlicher Schlüssel: Der öffentliche Schlüssel kann weit verbreitet werden und erfordert keine sichere Speicherung. Der entsprechende private Schlüssel kann nur mit dem öffentlichen Schlüssel verschlüsselte Nachrichten/Daten entschlüsseln.
Privat Schlüssel: Private Schlüssel werden vom Empfänger verwendet, um die mit dem entsprechenden öffentlichen Schlüssel verschlüsselten Nachrichten/Daten zu entschlüsseln. Dadurch wird der Eigentümer des privaten und öffentlichen Schlüsselpaars festgelegt und sichergestellt, dass die Nachricht nur von autorisierten Parteien gelesen werden kann.
Stammzertifizierungsstelle (Root CA): Ein Zertifikat gilt als gültig, wenn es von einer vertrauenswürdigen Stammzertifizierungsstelle signiert wurde. Eine Stammzertifizierungsstelle ist berechtigt, die Identität einer Person zu überprüfen und das an einen Benutzer verteilte Stammzertifikat zu signieren.
Zwischenzertifizierungsstelle: Eine Zwischenzertifizierungsstelle ist ebenfalls eine vertrauenswürdige Zertifizierungsstelle und dient als Kette zwischen der Stammzertifizierungsstelle und dem Clientzertifikat, für das sich der Benutzer registriert. Da die Stammzertifizierungsstelle die Zwischenzertifizierungsstelle signiert hat und ihr vertraut, sind auch die von der Zwischenzertifizierungsstelle generierten Zertifikate vertrauenswürdig.
Hardware-Sicherheitsmodul: A Hardware-Sicherheitsmodul ist kein obligatorischer Bestandteil einer PKI, verbessert aber die Sicherheit der PKI, wenn sie implementiert wird. Dieses Gerät schützt und verwaltet digitale Schlüssel und dient als Grundlage für den Aufbau einer sicheren Unternehmens-PKI Infrastruktur. Das HSM verwaltet den gesamten Lebenszyklus kryptografischer Schlüssel, einschließlich Erstellung, Rotation, Löschung, Prüfung und Unterstützung für APIs zur Integration mit verschiedenen Anwendungen.

Nachdem wir nun eine gute Vorstellung von einigen PKI-Komponenten haben, sprechen wir über verschiedene PKI-Anbieter und ihre Best Practices:

Microsoft PKI

Nachfolgend finden Sie einige Best Practices, die für die effektive Nutzung von Microsoft PKI empfohlen werden.

Erstellen Sie vor der Bereitstellung einen detaillierten Plan Ihrer PKI-Infrastruktur.
Vermeiden Sie die Installation von ADCS auf einem Domänencontroller.
Die Stammzertifizierungsstelle sollte eigenständig und offline sein.
Stellen Sie keine Zertifikate von einer Stammzertifizierungsstelle an End-Entitäten aus.
Aktivieren Sie Überwachungsereignisse sowohl für die Stammzertifizierungsstelle als auch für die ausstellende Zertifizierungsstelle.
Sichern Sie den privaten Schlüssel mit HSM (FIPS 140-2 Stufe 3)
Installieren Sie Enterprise CA nur, wenn Ihre CA ein Zertifikat für Geräte oder Benutzer ausstellt.
Es wird nicht empfohlen, Standardzertifikatvorlagen zu verwenden.
Der CRL-Verteilungspunkt sollte hochverfügbar sein.
Veröffentlichen Sie die Root-CA-CRL im Active Directory.
Der Hash-Algorithmus sollte mindestens SHA-2 (SHA 256 Bit).
Die Gültigkeitsdauer des Endteilnehmerzertifikats sollte maximal 2 Jahre betragen.

AWS-Zertifikatsmanager

Hier sind die 10 wichtigsten Best Practices, die wir für AWS Certificate Manager (ACM) identifiziert haben:

ACM-Zertifikatablaufprüfung: Stellen Sie sicher, dass abgelaufene SSL/TLS-Zertifikate von ACM verwaltet. Dadurch wird das Risiko eliminiert, ein ungültiges SSL/TLS-Zertifikat in Ressourcen einzusetzen, die das Front-End auslösen. Dies könnte auch zu einem Glaubwürdigkeitsverlust für das Unternehmen führen.
Gültigkeitsprüfung des ACM-Zertifikats: Stellen Sie sicher, dass Anfragen, die während der Ausstellung oder Erneuerung des SSL/TLS-Zertifikats eingehen, regelmäßig validiert werden.
Nutzung der Stammzertifizierungsstelle (CA): Es empfiehlt sich, die Nutzung der Stammzertifizierungsstelle möglichst gering zu halten. Amazon empfiehlt die Erstellung eines separaten Kontos für die Stammzertifizierungsstelle.
Der Schutz der Transportschicht ist für die Sicherheit unerlässlich. Es wird empfohlen, nur TLS Version 1.1 oder höher zu verwenden und kein SSL, da es nicht mehr sicher ist.
Wenn Sie Zertifikate anstelle von von ACM ausgestellten Zertifikaten importieren, stellen Sie sicher, dass die zum Generieren der privaten Schlüssel für SSL/TLS-Zertifikate verwendeten Schlüssel eine hohe Schlüsselstärke aufweisen, um einen Datenverstoß zu vermeiden.
Vermeiden Sie die Verwendung von Platzhalter-Domänenzertifikaten. Versuchen Sie stattdessen, für jede Domäne und Subdomäne ein ACM-Einzeldomänenzertifikat mit einem eigenen privaten Schlüssel auszustellen.
Erlauben Sie die Verwendung importierter Zertifikate nur von authentifizierten und vertrauenswürdigen Partnern Ihrer Organisation in ACM. Beim Importieren von Wildcard-Zertifikaten in AWS Certificate Manager (ACM) besteht ein hohes Sicherheitsrisiko, da der Benutzer möglicherweise über eine unverschlüsselte Kopie des privaten Schlüssels des Zertifikats verfügt.
Es wird empfohlen, in SSL/TLS-ACM-Zertifikaten immer einen vollqualifizierten Domänennamen (FQDN) zu verwenden.
Um einen Missbrauch der generierten Zertifikate zu vermeiden, führen Sie regelmäßig Audits der AWS-Umgebung auf vertrauenswürdige Zertifikate durch und validieren Sie die Auditberichte.
Aktivieren Sie AWS CloudTrail- und CloudWatch-Alarme: Die CloudTrail-Protokollierung hilft Ihnen, den Verlauf von AWS-API-Aufrufen zu verfolgen und AWS-Bereitstellungen zu überwachen. CloudTrail kann in Anwendungen integriert werden, um automatisierte Protokollierungs- und Überwachungsaktivitäten durchzuführen. Die Aktivierung der CloudWatch-Alarmfunktion hilft Ihnen, bei Verstößen gegen konfigurierte Metriken durch Benachrichtigungen zu warnen.

AWS ACM Private CA (ACM PCA)

Nachfolgend finden Sie die empfohlenen Best Practices, die Ihnen dabei helfen können, AWS ACM PCA effektiver zu nutzen.

AWS empfiehlt, alle Ihre Richtlinien und Praktiken für den Betrieb Ihrer CA zu dokumentieren, einschließlich CA-Hierarchie, Architekturdiagramm, Richtlinien für den CA-Validierungszeitraum, Pfadlänge usw.
Die oben beschriebene CA-Struktur und -Richtlinien können in zwei Dokumenten festgehalten werden: Certificate Policy (CP) und Certificate Practice Statement (CPS). Ein Framework zur Erfassung wichtiger Informationen zu Ihren CA-Vorgängen finden Sie in RFC 3647.
Die Stammzertifizierungsstelle sollte im Allgemeinen nur zum Ausstellen eines Zertifikats für Zwischenzertifizierungsstellen verwendet werden.
Es wird empfohlen, eine Stammzertifizierungsstelle und eine untergeordnete Zertifizierungsstelle in zwei verschiedenen AWS-Konten zu erstellen.
Die Rolle des CA-Administrators sollte von der Rolle der Benutzer getrennt sein, die Zugriff nur zum Ausstellen von Endentitätszertifikaten benötigen.
Aktivieren Sie die CloudTrail-Protokollierung, bevor Sie eine private Zertifizierungsstelle erstellen und betreiben. Mit CloudTrail können Sie einen Verlauf der AWS-API-Aufrufe für Ihr Konto abrufen, um Ihre AWS-Bereitstellungen zu überwachen.
Es empfiehlt sich, den privaten Schlüssel Ihrer privaten Zertifizierungsstelle regelmäßig zu aktualisieren. Sie können einen Schlüssel aktualisieren, indem Sie ein neues Zertifizierungsstellenzertifikat importieren oder die private Zertifizierungsstelle durch eine neue ersetzen.
Löschen Sie die nicht verwendete private CA dauerhaft.
ACM Private CA empfiehlt die Verwendung der Amazon S3 Block Public Access (BPA)-Funktion für Buckets mit CRLs. Dadurch wird vermieden, dass Details Ihrer privaten PKI potenziellen Angreifern unnötig preisgegeben werden. BPA ist eine bewährte S3-Methode und für neue Buckets standardmäßig aktiviert.

Google Cloud-Zertifizierungsstellendienste

In diesem Thema werden einige bewährte Methoden beschrieben, mit denen Sie den Certificate Authority Service effektiver nutzen können.

Rollen- und Zugriffskontrolle: Personen sollten nicht gleichzeitig mehrere Rollen zugewiesen bekommen. Alle Rolleninhaber sollten ausreichend über ihre Verantwortlichkeiten und Sicherheitspraktiken informiert und geschult werden. Wenn Sie einer Person verschiedene Berechtigungen zuweisen möchten, empfiehlt es sich, mithilfe von IAM eine benutzerdefinierte Rolle zu erstellen.
In den meisten Fällen empfiehlt es sich, die Enterprise-Stufe zu verwenden, um einen Zertifizierungsstellenpool (CA) zu erstellen, der Zertifikate an andere CAs und Endentitäten ausstellt.
Beim Erstellen eines CA-Pools wird empfohlen, die DevOps-Ebene sorgfältig zu berücksichtigen, da diese keinen Zertifikatswiderruf unterstützt.
Sichern Sie CA-Signaturschlüssel durch Nutzung von Cloud HSM.
Aktivieren Sie Cloud-Audit-Protokolle, um den Zugriff auf und die Verwendung von Cloud HSM-Signaturschlüsseln zu überwachen.
Es wird empfohlen, keine vorhandene externe CA mit ausgestellten Zertifikaten in den CA-Dienst zu importieren.
Für eine Stammzertifizierungsstelle und eine untergeordnete Zertifizierungsstelle wird empfohlen, die höchstmögliche Schlüsselgröße für die jeweilige Algorithmusfamilie zu verwenden.
- Für RSA beträgt die größte unterstützte Schlüsselgröße 4096 Bit.
- Für ECDSA beträgt die größte unterstützte Schlüsselgröße 384 Bit.
(Für untergeordnete Zertifizierungsstellen mit kürzerer Lebensdauer genügt es, kleinere Schlüssellängen zu verwenden, z. B. 2048 Bit für RSA oder 256 Bit für ECDSA .)
Es wird empfohlen, dass die Autoren der Zertifikatvorlage den Mitgliedern der Organisation, die diese Zertifikatvorlage verwenden könnten, die CA-Dienstbenutzerrolle zuweisen.

#	Kategorien	Microsoft PKI	AWS Certificate Manager (ACM)	AWS ACM Private CA (ACM PCA)	Google Cloud – Zertifizierungsstellendienste (CAS)
1	Stammzertifizierungsstelle	Die Stammzertifizierungsstelle wird vor Ort bereitgestellt und offline gehalten.	AWS Certificate Manager ist ein Dienst, mit dem Sie öffentliche/private SSL/TLS-Zertifikate für die Verwendung mit AWS-Diensten und intern verbundenen Ressourcen einfach bereitstellen, verwalten und einsetzen können.	Die Stammzertifizierungsstelle kann in der AWS-Cloud bereitgestellt werden, oder die ausstellende CA-CSR kann von der externen Stammzertifizierungsstelle signiert werden.	Root-CAs können in der Google Cloud bereitgestellt werden – Zertifizierungsstellendienste oder ausstellende CA-CSRs können von der externen Root-CA signiert werden.
2	Zertifikatsvorlage	Es wird nicht empfohlen, die Standardzertifikatvorlage zu verwenden. Zertifikatvorlagen können konfiguriert werden.	Verwenden Sie AWS CloudFormation-Vorlagen, um private Zertifikate mit AWS Certificate Manager (ACM) auszustellen.	ACM Private CA unterstützt vier Arten von Zertifikatvorlagen. Basisvorlage – vordefinierte Vorlagen, in denen keine Passthrough-Parameter zulässig sind. CSRPassthrough-Vorlagen – Vorlagen, die ihre entsprechenden Basisvorlagenversionen erweitern, indem sie CSR-Passthrough ermöglichen. APIPassthrough-Vorlagen – Vorlagen, die ihre entsprechenden Basisvorlagenversionen erweitern, indem sie API-Passthrough ermöglichen. APICSRPassthrough-Vorlagen – Vorlagen, die ihre entsprechenden Basisvorlagenversionen erweitern, indem sie sowohl API- als auch CSR-Passthrough zulassen.	In jedem Projekt und an jedem Standort im Google Cloud CAS-Dienst kann eine neue Zertifikatsvorlage erstellt werden.
3	Schlüsselalgorithmus und Schlüsselgröße	Microsoft PKI unterstützt die Schlüsselgröße gemäß NIST 800-Standard. Die Mindestschlüsselgröße beträgt 2048 Bit. Für CAs, deren Zertifikat in mehr als 15 Jahren abläuft, wird jedoch die Verwendung von RSA empfohlen. Der RSA-Wert muss mindestens 4096 betragen. Bei ECC-Schlüsseln muss der CA-Schlüssel entweder die Kurve P-384 oder P-521 verwenden.	Die folgenden Public-Key-Algorithmen und Schlüsselgrößen werden von ACM unterstützt: 2048-Bit-RSA (RSA_2048) 3072-Bit-RSA (RSA_3072) 4096-Bit-RSA (RSA_4096) Elliptische Primkurve 256 Bit (EC_prime256v1) Elliptische Primzahlkurve 384 Bit (EC_secp384r1) Elliptische Primzahlkurve 384 Bit (EC_secp384r1)	AWS ACM Private CA unterstützt den folgenden kryptografischen Algorithmus und die folgende Schlüsselgröße für die Generierung privater Schlüssel. Mit der erweiterten Option sind folgende Algorithmen verfügbar: (Diese Liste gilt nur für Zertifikate, die direkt von ACM Private CA über die Konsole, API oder Befehlszeile ausgestellt wurden.) RSA2048 RSA4096 ECDSA P256 ECDSA P384	In der Google Cloud werden der folgende Schlüsselalgorithmus und die folgende Schlüsselgröße verwendet: 2048-Bit-RSA (RSA_2048) 3072-Bit-RSA (RSA_3072) 4096-Bit-RSA (RSA_4096) ECDSA P256 ECDSA P384 Für eine neue Stammzertifizierungsstelle oder eine untergeordnete Zertifizierungsstelle mit einer erwarteten Lebensdauer von mehreren Jahren empfiehlt Google die Verwendung der größten verfügbaren Schlüsselgröße für die jeweilige Algorithmusfamilie. (Für RSA beträgt die größte unterstützte Schlüsselgröße 4096 Bit, für ECDSA 384 Bit.)
4	Hashing-Algorithmus	Es wird empfohlen, für die neue Bereitstellung und die vorhandene PKI den erweiterten Hashing-Algorithmus (SHA 256 und höher) zu verwenden.	Im AWS Certificate Manager verwaltete Zertifikate verwenden RSA-Schlüssel mit einem 2048-Bit-Modul und SHA-256. ACM ist derzeit nicht in der Lage, andere Zertifikate wie ECDSA-Zertifikate zu verwalten.	ACM Private CA unterstützt den folgenden Zertifikatsignaturalgorithmus. Diese Liste gilt nur für Zertifikate, die direkt von ACM Private CA über die Konsole, API oder Befehlszeile ausgestellt werden. SHA256WITHECDSA SHA384WITHECDSA SHA512WITHECDSA SHA256WITHRSA SHA384WITHRSA SHA512WITHRSA	Die Zertifizierungsstellendienste von Google Cloud unterstützen SHA256 und SHA384.
5	RFC-Konformität	CA-Zertifikate innerhalb der Microsoft IT PKI müssen X.509 Version 3 entsprechen und RFC 5280: Internet X.509 Public Key Infrastructure Certificate and CRL Profile vom Mai 2008 entsprechen. Je nach Zertifikatstyp entsprechen die Zertifikate der aktuellen Version der CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly Trusted Certificates.	AWS Certificate Manager ist für den Schutz der Infrastruktur verantwortlich, auf der AWS-Dienste in der AWS-Cloud ausgeführt werden. AWS bietet zudem sicher nutzbare Dienste an. Externe Prüfer testen und verifizieren die Wirksamkeit der Sicherheit regelmäßig im Rahmen der AWS-Compliance-Programme (https://aws.amazon.com/compliance/programs/)	Bestimmte für eine private CA geltende Einschränkungen werden gemäß RFC 5280 durchgesetzt. ACM Private CA setzt jedoch nicht alle in RFC 5280 definierten Einschränkungen durch.	Der Certificate Authority Service verwendet das Tool ZLint, um sicherzustellen, dass X.509-Zertifikate gemäß den RFC 5280-Regeln gültig sind. Der CA Service setzt jedoch nicht alle RFC 5280-Anforderungen durch, und es ist möglich, dass eine mit dem CA Service erstellte CA ein nicht konformes Zertifikat ausstellt.
6	CRL-Verteilungspunkt (Certificate Revocation List)	Microsoft PKI hinterlegt die CRL unter LDAP (Lightweight Directory Access Protocol) und HTTP.	Das AWS-Supportcenter kann Ihnen beim Widerruf eines Zertifikats im AWS Certificate Manager helfen. Sie müssen hierfür ein Support-Ticket/einen Support-Fall erstellen.	ACM Private CA hinterlegt die CRL automatisch im von Ihnen angegebenen Amazon S3-Bucket.	Damit ein CA-Pool die CRL veröffentlichen kann, muss die CRL-Veröffentlichung aktiviert sein. Die CRL-Veröffentlichung kann während der Erstellung eines CA-Pools aktiviert werden.
7	Speicherung privater Schlüssel	Es wird empfohlen, die privaten Schlüssel in einem FIPS 140-2 Level 3-kompatiblen HSM zu speichern	AWS Certificate Manager speichert das Zertifikat und den entsprechenden privaten Schlüssel und verwendet AWS Key Management Service (AWS KMS), um den privaten Schlüssel zu schützen.	Standardmäßig werden die privaten Schlüssel für private Zertifizierungsstellen in von AWS verwalteten Hardware-Sicherheitsmodellen (HSMs) gespeichert. Die HSMs entsprechen den Sicherheitsanforderungen für kryptografische Module gemäß FIPS PUB 140-2.	CA-Schlüssel werden in Cloud HSM gespeichert, sind FIPS 140-2 Level 3-validiert und in Regionen in Nord- und Südamerika, Europa und im asiatisch-pazifischen Raum verfügbar.
8	Prüfungsberichte	Die Überwachung kann auf einer Zertifizierungsstelle in einem Windows-Server aktiviert werden, um ein Überwachungsprotokoll für alle Aufgaben der Zertifikatdienstverwaltung bereitzustellen.	AWS Certificate Manager (ACM) ist in AWS CloudTrail integriert, einen Service, der Aktionen eines Benutzers, einer Rolle oder eines AWS-Service in ACM aufzeichnet. CloudTrail ist in Ihrem AWS-Konto standardmäßig aktiviert.	Es werden Prüfberichte erstellt, um alle Zertifikate aufzulisten, die die private ACM-Zertifizierungsstelle ausgestellt oder widerrufen hat. Der Bericht wird in einem neuen oder vorhandenen angegebenen S3-Bucket gespeichert.	Cloud-Audit-Protokolle können in Zertifizierungsstellendiensten verwendet werden. Cloud-Audit-Protokolle bieten die folgenden Audit-Protokolle für jedes Cloud-Projekt, jeden Ordner und jede Organisation: Überwachungsprotokolle für Administratoraktivitäten Datenzugriffs-Auditprotokolle Systemereignis-Überwachungsprotokolle Überwachungsprotokolle für abgelehnte Richtlinien
9	Best Practices (auf hohem Niveau)	Erstellen Sie vor der Bereitstellung einen detaillierten Plan Ihrer PKI-Infrastruktur. Vermeiden Sie die Installation von ADCS auf einem Domänencontroller. Die Stammzertifizierungsstelle sollte eigenständig und offline sein. Stellen Sie keine Zertifikate von einer Stammzertifizierungsstelle an End-Entitäten aus. Aktivieren Sie Überwachungsereignisse sowohl für die Stammzertifizierungsstelle als auch für die ausstellende Zertifizierungsstelle. Sichern Sie den privaten Schlüssel mit HSM (FIPS 140-2 Level 3) (Weitere Einzelheiten im vorherigen Abschnitt)	ACM-Zertifikatablaufprüfung: Stellen Sie sicher, dass abgelaufene SSL/TLS-Zertifikate, die von ACM verwaltet werden, entfernt werden. Dadurch wird das Risiko eliminiert, ein ungültiges SSL/TLS-Zertifikat in Ressourcen einzusetzen, die das Front-End auslösen. Dies könnte auch zu einem Glaubwürdigkeitsverlust für das Unternehmen führen. Gültigkeitsprüfung des ACM-Zertifikats: Stellen Sie sicher, dass Anfragen, die während der Ausstellung oder Erneuerung des SSL/TLS-Zertifikats eingehen, regelmäßig validiert werden. Nutzung der Stammzertifizierungsstelle (CA): Es empfiehlt sich, die Nutzung der Stammzertifizierungsstelle möglichst gering zu halten. Amazon empfiehlt die Erstellung eines separaten Kontos für die Stammzertifizierungsstelle. Der Schutz der Transportschicht ist für die Sicherheit unerlässlich. Es wird empfohlen, nur TLS Version 1.1 oder höher zu verwenden und kein SSL, da es nicht mehr sicher ist. (Weitere Einzelheiten im vorherigen Abschnitt)	Empfohlene Best Practices zur effektiven Nutzung von ACM PCA: Dokumentieren der CA-Struktur und -Richtlinien. Minimieren Sie die Verwendung der Stammzertifizierungsstelle. Geben Sie der Stammzertifizierungsstelle ein eigenes AWS-Konto. Separate Administrator- und Ausstellerrollen. Aktivieren Sie die CloudTrail-Anmeldung. Rotieren Sie den privaten CA-Schlüssel. Löschen Sie eine nicht verwendete CA (AWS stellt Ihnen eine CA in Rechnung, bis sie gelöscht wird).	Rollen- und Zugriffskontrolle: Personen sollten nicht gleichzeitig mehrere Rollen zugewiesen bekommen. Alle Rolleninhaber sollten ausreichend über ihre Verantwortlichkeiten und Sicherheitspraktiken informiert und geschult werden. Wenn Sie einer Person verschiedene Berechtigungen zuweisen möchten, empfiehlt es sich, mithilfe von IAM eine benutzerdefinierte Rolle zu erstellen. In den meisten Fällen empfiehlt es sich, die Enterprise-Stufe zu verwenden, um einen Zertifizierungsstellenpool (CA) zu erstellen, der Zertifikate an andere CAs und Endentitäten ausstellt. Beim Erstellen eines CA-Pools wird empfohlen, die DevOps-Ebene sorgfältig zu berücksichtigen, da diese keinen Zertifikatswiderruf unterstützt. (Weitere Einzelheiten im vorherigen Abschnitt)
10	CA-Hierarchie	In einer hierarchischen PKI (einer typischen Bereitstellung) gibt es im Allgemeinen drei Arten von Hierarchien: einschichtig, zweischichtig und dreischichtig.	AWS Certificate Manager ist ein Dienst, mit dem Sie öffentliche/private SSL/TLS-Zertifikate mit AWS-Diensten und intern verbundenen Ressourcen einfach bereitstellen, verwalten und einsetzen können.	Mit ACM PCA können Sie eine Hierarchie von Zertifizierungsstellen mit bis zu fünf Ebenen entwerfen und erstellen.	Beim Erstellen einer untergeordneten Zertifizierungsstelle, die mit einer externen Stammzertifizierungsstelle verknüpft ist, müssen die Eigenschaften der vom CA-Dienst generierten CSR im von der externen Stammzertifizierungsstelle signierten Zertifizierungsstellenzertifikat beibehalten werden. Die externe Zertifizierungsstelle kann zusätzliche Erweiterungen hinzufügen, sofern sie die Eigenschaften der CSR beibehält. Beispielsweise muss das signierte untergeordnete Zertifizierungsstellenzertifikat dieselbe Pfadlängenbeschränkung enthalten, wenn die CSR eine Pfadlängenbeschränkung enthält.
11	Redundanz und Notfallwiederherstellung	Redundanz- und Notfallwiederherstellungspläne sollten während der Entwurfs- und Implementierungsplanungsphase einer PKI-Bereitstellung vollständig sein.	ACM verfügt über kein SLA. Der von der ACM Private Certificate Authority verwaltete private CA-Dienst verfügt über ein SLA.	ACM Private CA ist in mehreren Regionen verfügbar, sodass der Benutzer redundante CAs erstellen kann. Der ACM Private CA-Dienst arbeitet mit einem Service Level Agreement (SLA) mit einer Verfügbarkeit von 99.9 %.	Die Google Cloud Certificate Authority-Dienste (CAS) sind in mehreren Regionen verfügbar, was Redundanz ermöglicht. Google Cloud (CAS) arbeitet mit einem Service Level Agreement (SLA) mit einer Verfügbarkeit von 99.9 %.

Fazit

Die Public-Key-Infrastruktur (PKI) spielt eine entscheidende Rolle für die sichere Kommunikation durch den Einsatz digitaler Zertifikate. Die Kombination wichtiger Komponenten wie Zertifizierungsstellen (CAs) und Registrierungsstellen (RAs) dient der Authentifizierung von Entitäten und der Verwaltung des Zertifikatslebenszyklus. Durch die Verschlüsselung mit öffentlichen und privaten Schlüsselpaaren gewährleistet die PKI die Vertraulichkeit und Authentizität von Daten und somit die Sicherheit der Infrastruktur.

Verschiedene Anbieter stellen maßgeschneiderte PKI-Lösungen bereit , die jeweils unterschiedliche Vorteile für spezifische Anwendungsfälle bieten. Microsoft PKI setzt auf sicheres Schlüsselmanagement mit Offline-Root-CAs und Hardware-Sicherheitsmodulen (HSMs). AWS Certificate Manager (ACM) bietet automatisiertes Zertifikatsmanagement mit Fokus auf Validierung und Sicherheit für Cloud-Ressourcen. Der Zertifizierungsstellendienst von Google Cloud legt Wert auf rollenbasierte Zugriffskontrolle und die Verwendung starker Verschlüsselungsschlüssel. Diese anbieterspezifischen Empfehlungen gewährleisten eine hochsichere PKI-Implementierung auf verschiedenen Plattformen und in unterschiedlichen Umgebungen.

Wie kann Encryption Consulting helfen?

Bei Encryption Consulting sind wir auf die Konzeption und Migration von PKI-Infrastrukturen spezialisiert, die optimal auf die individuellen Sicherheitsanforderungen Ihres Unternehmens abgestimmt sind. Wir bieten umfassende Dienstleistungen für PKI-Design und -Implementierung – sowohl für bestehende als auch für neue PKI-Infrastrukturen. Unsere On-Premises-Lösungen umfassen Microsoft PKI, während unsere Cloud-basierten PKI-Lösungen führende Cloud-Service-Anbieter wie AWS Certificate Manager, AWS Certificate Manager Private CA (ACM-PCA), Azure PKI und Google Cloud Certificate Authority Manager nutzen.