Der Certificate Authority Service vereinfacht, automatisiert und individualisiert Bereitstellung, Verwaltung und Sicherheit privater Certificate Authorities (CA). Wir stellen Ihnen drei verschiedene Designoptionen für Ihren Google Cloud Certificate Authority Service vor.
Drei Ansätze, um Root- und untergeordnete Certificate Authorities in Ihren Google Cloud-Projekten und Ihrer Organisation miteinander zu verbinden
Der Certificate Authority Service ist ein vollständig verwalteter Dienst, mit dem Sie die Bereitstellung, Verwaltung und Sicherheit privater Certificate Authorities (CA) vereinfachen, automatisieren und individuell anpassen können.
Wenn Ihre Organisation aktuell private Zertifikate für Workloads und interne SSL-Load-Balancer in Google Cloud bereitstellt und verwaltet, können Sie mit dem Certificate Authority Service die manuelle Erstellung und Rotation von Zertifikaten überflüssig machen und strenge Zugriffskontrollen durchsetzen.
Dieser Artikel zeigt die Vor- und Nachteile von drei Designoptionen für die Implementierung eines Certificate Authority Service – also drei verschiedene Wege, Root- und untergeordnete CAs in Ihren Google Cloud-Projekten und Ihrer Organisation miteinander zu verbinden.
Alle Optionen setzen auf die Service-Stufe Enterprise CA Pool (im Gegensatz zur eingeschränkteren DevOps-Stufe) und auf eine zweistufige Hierarchie der Certificate Authorities. (Mehr Ebenen sind möglich, ich empfehle jedoch maximal drei.)
Option 1: CA-Setup auf Organisationsebene
In dieser Architektur richten wir eine einzige Root-CA und je eine untergeordnete CA pro Umgebung ein. Das ist die unkomplizierteste Variante: Sie erlaubt es, alle CAs und Zertifikate zentral zu verwalten und die nötigen IAM-Richtlinien einheitlich durchzusetzen.
Auf allen Clients muss nur eine einzige Root-CA installiert werden. Über die Certificate Issuance Policy stellen Sie sicher, dass jede untergeordnete CA ausschließlich Zertifikate für die vorgesehenen Domains ausstellen kann.
Der Nachteil dieser Option: Eine einzige Root-CA bedeutet, dass alle Clients sämtlichen Zertifikaten in allen Umgebungen vertrauen (Produktivsysteme vertrauen also auch Pre-Produktionssystemen und umgekehrt).
Bei einem einzigen Root-CA-Setup ist das Testen von Änderungen schwierig, da sich Fehlkonfigurationen auf alle untergeordneten CAs auswirken. Vermeiden Sie deshalb Änderungen an der Root-CA und rollen Sie stattdessen neue untergeordnete CAs aus, um Anpassungen zu testen.
Option 2: CA-Setup pro Umgebungstyp
In dieser Architektur richten wir je eine eigene Root-CA und untergeordnete CA pro Umgebungstyp ein. Alle CAs liegen in einem einzigen Projekt und trennen Produktion von Pre-Produktion, während die übrigen Cloud-Ressourcen in separaten Projekten liegen – etwa für Development, Pre-Produktion und Produktion.
Je nach Umgebungstyp beziehen die im Projekt laufenden Services das benötigte Zertifikat von der untergeordneten CA. Über eine Certificate Issuance Policy stellen wir sicher, dass jede untergeordnete CA nur Zertifikate für die vorgesehenen Domains ausstellt.
So lassen sich Änderungen in einer niedrigeren Umgebung testen, bevor sie in die Produktion ausgerollt werden.
Der Nachteil dieser Option: Je nach Umgebungstyp müssen unterschiedliche Root-CAs auf den jeweiligen Clients installiert werden.
Option 3: CA-Setup pro Projekt
In dieser Architektur richten wir je eine eigene Root-CA und untergeordnete CA pro Projekt ein und erreichen damit eine vollständige Trennung. Änderungen lassen sich problemlos in einer niedrigeren Umgebung testen, ohne andere CA-Setups zu beeinflussen.
Mehrere Root-CAs bedeuten, dass wir je nach Umgebung unterschiedliche Root-CAs auf den Clients installieren müssen.
Soll umgebungsübergreifendes Vertrauen bestehen, müssen mehrere Root-CAs auf dem jeweiligen Client installiert werden.
Das ist die komplexeste Option in Bezug auf Architektur und Wartung, bietet aber Sicherheit durch konsequente Trennung.
Fazit
Welche Designoption für den Certificate Authority Service die richtige ist, hängt davon ab, wie Ihre Organisation Sicherheitsanforderungen, einfache Verwaltung und niedrige Kosten gegeneinander abwägt.
Sprechen Sie uns an, um mehr über die Zusammenarbeit mit DoiT zu erfahren. Wir unterstützen Sie gerne beim Design des Certificate Authority Service (CAS) oder bei anderen Cloud-Themen.