Entwerfen einer CA-Hierarchie

Mit AWS Private CA können Sie eine Hierarchie von Zertifizierungsstellen mit bis zu fünf Ebenen erstellen. Die Stamm-CA im oberen Bereich einer Hierarchiestruktur kann eine beliebige Anzahl von Verzweigungen aufweisen. Die Stamm-CA kann bis zu vier Ebenen untergeordneter CAs in jedem Zweig aufweisen. Sie können auch mehrere Hierarchien erstellen, jede mit einem eigenen Stamm.

Eine gut gestaltete CA-Hierarchie bietet folgende Vorteile:

• Detaillierte Sicherheitskontrollen, die für die einzelnen CAs geeignet sind

• Aufteilung von administrativen Aufgaben für besseren Lastausgleich und Sicherheit

• Verwendung von CAs mit begrenzter, widerruflicher Vertrauensstellung für den täglichen Betrieb

• Gültigkeitszeiträume und Zertifikatspfadbeschränkungen

Das folgende Diagramm veranschaulicht eine einfache CA-Hierarchie mit drei Ebenen.

Jede Zertifizierungsstelle in der Struktur wird durch ein X.509 v3-Zertifikat mit Signaturberechtigung (symbolisiert durch das pen-and-paper Symbol) unterstützt. Das bedeutet, dass sie als CAs andere untergeordnete Zertifikate signieren können. Wenn eine CA das Zertifikat einer untergeordneten CA signiert, verleiht sie dem signierten Zertifikat eine eingeschränkte, widerrufliche Autorität. Die Stamm-CA auf Ebene 1 signiert untergeordnete CA-Zertifikate auf Ebene 2. Diese CAs wiederum signieren Zertifikate für CAs auf Ebene 3, die von PKI-Administratoren (Public Key-Infrastruktur) verwendet werden, die Endentitätszertifikate verwalten.

Sicherheit in einer CA-Hierarchie sollte so konfiguriert werden, dass sie im oberen Bereich der Struktur am stärksten ist. Diese Anordnung schützt das Stamm-CA-Zertifikat und seinen privaten Schlüssel. Die Stamm-CA verankert die Vertrauensstellung für alle untergeordneten CAs und die darunter liegenden Endentitätszertifikate. Während lokaler Schaden durch die Kompromittierung eines Endentitätszertifikats entstehen kann, zerstört die Kompromittierung des Stammes die Vertrauensstellung in der gesamten PKI. Stammzertifizierungsstellen und untergeordnete Zertifizierungsstellen auf hoher Ebene werden nur selten verwendet (normalerweise zum Signieren anderer CA-Zertifikate). Folglich werden sie streng kontrolliert und geprüft, um ein geringeres Risiko von Kompromittierungen zu gewährleisten. Auf den unteren Ebenen der Hierarchie ist die Sicherheit weniger restriktiv. Dieser Ansatz ermöglicht die routinemäßigen Verwaltungsaufgaben beim Ausstellen und Widerrufen von Endentitätszertifikaten für Benutzer, Computer-Hosts und Softwaredienste.

Anmerkung

Die Verwendung einer Stamm-CA zum Signieren eines untergeordneten Zertifikats ist ein seltenes Ereignis, das nur unter einer Handvoll von Umständen auftritt:

• Wenn die PKI erstellt wird

• Wenn eine CA auf hoher Ebene ersetzt werden muss

• Wenn eine Zertifikatssperrliste (CRL) oder ein OCSP-Responder (Online Certificate Status Protocol) konfiguriert werden muss

Stamm-CAs und andere CA auf hoher Ebene erfordern in hohem Maße sichere Betriebsprozesse und Zugriffssteuerungsprotokolle.

Validierung von Endzertifizierungszertifikaten

Endentitätszertifikate leiten ihre Vertrauensstellung von einem Zertifizierungspfad ab, der durch die untergeordneten CAs zu einer Stamm-CA führt. Wenn einem Webbrowser oder einem anderen Client ein Endentitätszertifikat präsentiert wird, versucht er, eine Vertrauenskette zu erstellen. Beispielsweise überprüft er etwa, ob der definierte Name (Distinguished Name) des Ausstellers und der definierte Name des Subjekts des Zertifikats mit den entsprechenden Feldern des ausstellenden CA-Zertifikats übereinstimmen. Der Abgleich würde dann auf jeder aufeinanderfolgenden Ebene in der Hierarchie nach oben fortgesetzt, bis der Client eine vertrauenswürdige Stamm-CA erreicht, die in seinem Trust Store (Vertrauensspeicher) enthalten ist.

Der Vertrauensspeicher ist eine Bibliothek vertrauenswürdiger CAs, die der Browser oder das Betriebssystem enthält. Bei einer privaten PKI muss die IT Ihrer Organisation sicherstellen, dass jeder Browser oder jedes System die private Stamm-CA vorab dem Vertrauensspeicher hinzugefügt hat. Andernfalls kann der Zertifizierungspfad nicht validiert werden, was zu Client-Fehlern führt.

Das nächste Diagramm zeigt den Validierungspfad, dem ein Browser folgt, wenn ein X.509-Endentitätszertifikat vorliegt. Beachten Sie, dass das Endentitätszertifikat keine Signaturautorität besitzt und nur dazu dient, die Entität zu authentifizieren, die es besitzt.

Der Browser überprüft das Endentitätszertifikat. Der Browser stellt fest, dass das Zertifikat eine Signatur von der untergeordneten CA (Ebene 3) als vertrauenswürdige Anmeldeinformationen anbietet. Die Zertifikate für die untergeordneten CAs müssen in derselben PEM-Datei enthalten sein. Alternativ können sie sich auch in einer separaten Datei befinden, die die Zertifikate enthält, aus denen die Vertrauenskette besteht. Sind diese gefunden, überprüft der Browser das Zertifikat der untergeordneten CA (Ebene 3) und stellt fest, dass es eine Signatur von der untergeordneten CA (Ebene 2) bietet. Die untergeordnete CA (Ebene 2) bietet wiederum eine Signatur von der Stamm-CA (Ebene 1) als vertrauenswürdige Anmeldeinformationen. Wenn der Browser eine Kopie des privaten Stamm-CA-Zertifikats findet, das in seinem Vertrauensspeicher vorinstalliert ist, validiert er das Endentitätszertifikat als vertrauenswürdig.

In der Regel überprüft der Browser auch jedes Zertifikat anhand einer Zertifikatsperrliste (CRL). Ein abgelaufenes, gesperrtes oder falsch konfiguriertes Zertifikat wird abgelehnt und die Validierung schlägt fehl.

Planung der Struktur einer CA-Hierarchie

Im Allgemeinen sollte Ihre CA-Hierarchie die Struktur Ihrer Organisation widerspiegeln. Streben Sie eine Pfadlänge (d. h. die Anzahl der CA-Ebenen) an, die nicht größer ist als für die Delegierung von Verwaltungs- und Sicherheitsrollen erforderlich. Das Hinzufügen einer CA zur Hierarchie bedeutet, die Anzahl der Zertifikate im Zertifizierungspfad zu erhöhen, was die Validierungsdauer erhöht. Wenn Sie die Pfadlänge auf ein Minimum beschränken, wird auch die Anzahl der Zertifikate reduziert, die bei der Validierung eines Endzertifikats vom Server an den Client gesendet werden.

Theoretisch kann eine Stammzertifizierungsstelle, die keinen pathLenConstraintParameter hat, beliebig viele untergeordnete Zertifizierungsstellen autorisieren. Eine untergeordnete Zertifizierungsstelle kann so viele untergeordnete Zertifizierungsstellen haben, wie es ihre interne Konfiguration zulässt. AWS Private CA verwaltete Hierarchien unterstützen Zertifizierungsstellen mit einer Tiefe von bis zu fünf Ebenen.

Gut gestaltete CA-Strukturen haben mehrere Vorteile:

• Separate Verwaltungskontrollen für verschiedene Organisationseinheiten

• Die Möglichkeit, den Zugriff auf untergeordnete CAs zu delegieren

• Eine hierarchische Struktur, die CAs höherer Ebenen mit zusätzlichen Sicherheitskontrollen schützt

Zwei häufige CA-Strukturen erfüllen all dies:

• Zwei CA-Ebenen: Stamm-CA und untergeordnete CA

  Dies ist die einfachste CA-Struktur, die separate Verwaltungs-, Kontroll- und Sicherheitsrichtlinien für die Stamm-CA und eine untergeordnete CA ermöglicht. Sie können restriktive Kontrollen und Richtlinien für Ihre Stamm-CA aufrechterhalten und gleichzeitig der untergeordneten CA weitreichenderen Zugriff gewähren. Letzteres wird für die Massenausgabe von Endentitätszertifikaten verwendet.

• Drei CA-Ebenen: Stamm-CA und zwei Ebenen untergeordneter CAs

  Ähnlich wie oben fügt diese Struktur eine zusätzliche CA-Ebene hinzu, um die Stamm-CA weiter von CA-Operationen auf niedriger Ebene zu trennen. Die mittlere CA-Ebene wird nur verwendet, um untergeordnete CAs zu signieren, die die Ausstellung von Endentitätszertifikaten durchführen.

Zu den selteneren CA-Strukturen gehören die folgenden:

• Vier oder mehr CA-Ebenen

  Obwohl weniger häufig als Hierarchien mit drei Ebenen, sind CA-Hierarchien mit vier oder mehr Ebenen möglich und unter Umständen erforderlich, um die Delegierung administrativer Aufgaben zu ermöglichen.

• Eine CA-Ebene: nur Stamm-CA

  Diese Struktur wird häufig für die Entwicklung und das Durchführen von Tests verwendet, wenn keine vollständige Vertrauenskette erforderlich ist. Ihre Verwendung in der Produktion ist untypisch. Darüber hinaus verstößt sie gegen die bewährten Methoden zur Aufrechterhaltung separater Sicherheitsrichtlinien für die Stamm-CA und die CAs, die Endentitätszertifikate ausstellen.

  Wenn Sie jedoch bereits Zertifikate direkt von einer Stammzertifizierungsstelle ausstellen, können Sie zu AWS Private CA dieser migrieren. Dies bietet Sicherheits- und Kontrollvorteile gegenüber der Verwendung einer Root-CA, die mit OpenSSL oder anderer Software verwaltet wird.

Beispiel für eine private PKI für einen Hersteller

In diesem Beispiel stellt ein hypothetisches Technologieunternehmen zwei IoT-Produkte (Internet of Things) her, eine intelligente Glühbirne und einen intelligenten Toaster. Während der Produktion wird für jedes Gerät ein Endentitätszertifikat ausgestellt, damit es sicher über das Internet mit dem Hersteller kommunizieren kann. Die PKI des Unternehmens sichert auch seine Computerinfrastruktur, einschließlich der internen Website und verschiedener selbst gehosteter Computerdienste, die Finanz- und Geschäftsabläufe ausführen.

Folglich ist die CA-Hierarchie eng an diesen administrativen und operativen Aspekten des Geschäfts ausgerichtet.

Diese Hierarchie enthält drei Stamm-CAs, eine für interne Vorgänge und zwei für externe Vorgänge (eine Stamm-CA für jede Produktlinie). Es zeigt auch mehrere Zertifizierungspfade mit zwei Zertifizierungsstufen für interne Abläufe und drei Stufen für externe Abläufe.

Die Verwendung getrennter Stammzertifizierungsstellen und zusätzlicher untergeordneter Zertifizierungsstellen auf Seiten des externen Betriebs ist eine Designentscheidung, die den Geschäfts- und Sicherheitsanforderungen gerecht wird. Mit mehreren CA-Strukturen ist die PKI zukunftssicher im Fall von Unternehmensumstrukturierungen, Veräußerungen oder Akquisitionen. Wenn Änderungen auftreten, kann eine gesamte CA-Stammhierarchie mit der Abteilung, die sie sichert, ordnungsgemäß bewegt werden. Und mit zwei Ebenen untergeordneter CAs weisen die Stamm-CAs eine hohe Isolation von den CAs der Ebene 3 auf, die für die Massensignierung der Zertifikate für Tausende oder Millionen von hergestellten Artikeln verantwortlich sind.

Auf der internen Seite vervollständigen Internet- und interne Computervorgänge des Unternehmens eine Hierarchie mit zwei Ebenen. Diese Ebenen ermöglichen es Webadministratoren und Betriebsingenieuren, die Zertifikatausstellung unabhängig für ihre eigenen Geschäftsdomänen zu verwalten. Die Aufteilung der PKI in verschiedene funktionale Domänen ist eine bewährte Methode im Bereich Sicherheit und schützt sie vor einer Kompromittierung, die sich auf die jeweils andere auswirken könnte. Webadministratoren stellen Endentitätszertifikate zur Verwendung durch Webbrowser im gesamten Unternehmen aus und authentifizieren und verschlüsseln so die Kommunikation auf der internen Website. Betriebsingenieure stellen Endentitätszertifikate aus, die Rechenzentrums-Hosts und Computerdienste gegenseitig authentifizieren. Dieses System trägt dazu bei, vertrauliche Daten zu schützen, indem es sie im LAN verschlüsselt.

Festlegung von Längenbeschränkungen für den Zertifizierungspfad

Die Struktur einer CA-Hierarchie wird durch die Erweiterung der Basiseinschränkungen definiert und erzwungen, die jedes Zertifikat enthält. Die Erweiterung definiert zwei Einschränkungen:

• cA— Ob das Zertifikat eine Zertifizierungsstelle definiert. Wenn dieser Wert false lautet (der Standardwert), ist das Zertifikat ein Endentitätszertifikat.

• pathLenConstraint— Die maximale Anzahl untergeordneter Zertifizierungsstellen, die in einer gültigen Vertrauenskette existieren können. Das Zertifikat der Endeinheit wird nicht gezählt, da es sich nicht um ein CA-Zertifikat handelt.

Ein Stamm-CA-Zertifikat erfordert maximale Flexibilität und enthält keine Pfadlängenbeschränkung. Dadurch kann der Stamm einen Zertifizierungspfad beliebiger Länge definieren.

Anmerkung

AWS Private CA begrenzt den Zertifizierungspfad auf fünf Stufen.

Untergeordnete CAs haben pathLenConstraint-Werte größer oder gleich Null, abhängig von der Position in der Hierarchie und den gewünschten Funktionen. Beispielsweise wird in einer Hierarchie mit drei CAs keine Pfadbeschränkung für die Stamm-CA angegeben. Die erste untergeordnete CA hat eine Pfadlänge von 1 und kann daher untergeordnete CAs signieren. Jede dieser untergeordneten CAs muss notwendigerweise einen pathLenConstraint-Wert von Null haben. Dies bedeutet, dass sie Endentitätszertifikate signieren, jedoch keine zusätzlichen CA-Zertifikate ausstellen können. Die Begrenzung der Berechtigung, neue CAs zu erstellen, ist eine wichtige Sicherheitskontrolle.

Das folgende Diagramm veranschaulicht diese Verbreitung von eingeschränkter Autorität in der Hierarchie.

In dieser Hierarchie mit vier Ebenen ist die Stamm-CA nicht eingeschränkt (wie immer). Aber die erste untergeordnete CA hat einenpathLenConstraint-Wert von 2, wodurch ihre untergeordneten CAs nicht mehr als zwei Ebenen tiefer gehen. Folglich muss der Einschränkungswert für einen gültigen Zertifizierungspfad in den nächsten beiden Ebenen auf Null verringert werden. Wenn ein Webbrowser ein Endentitätszertifikat aus diesem Zweig vorfindet, das eine Pfadlänge größer als vier hat, schlägt die Validierung fehl. Ein solches Zertifikat könnte auf eine versehentlich erstellte CA, eine falsch konfigurierte CA oder eine nicht autorisierte Ausstellung zurückzuführen sein.

Verwaltung der Pfadlänge mit Vorlagen

AWS Private CA stellt Vorlagen für die Ausstellung von Stamm-, untergeordneten und Endentitätszertifikaten bereit. Diese Vorlagen fassen bewährte Methoden für die grundlegenden Einschränkungswerte, einschließlich der Pfadlänge, zusammen. Die Vorlagen umfassen die folgenden:

• RootCACertificate/V1

• Untergeordnetes CA-Zertifikat _ 0/V1 PathLen

• Untergeordnetes CA-Zertifikat _ 1/V1 PathLen

• Untergeordnetes CA-Zertifikat _ 2/V1 PathLen

• Untergeordnetes CA-Zertifikat _ 3/V1 PathLen

• EndEntityCertificate/V1

Die IssueCertificate-API gibt einen Fehler zurück, wenn Sie versuchen, eine CA mit einer Pfadlänge zu erstellen, die größer oder gleich der Pfadlänge des ausstellenden CA-Zertifikats ist.

Weitere Informationen zu Zertifikatvorlagen finden Sie unter Grundlegendes zu Zertifikatsvorlagen.

Automatisieren der Einrichtung der CA-Hierarchie mit AWS CloudFormation

Wenn Sie sich für ein Design für Ihre CA-Hierarchie entschieden haben, können Sie es testen und mithilfe einer AWS CloudFormation Vorlage in Produktion nehmen. Ein Beispiel für eine solche Vorlage finden Sie unter Deklarieren einer privaten CA-Hierarchie im AWS CloudFormation -Benutzerhandbuch.