Zertifizierungsstelle Cloud vs OnPrem
Wann Cloud-PKI sinnvoll ist, wo ADCS bleibt – und warum Hybrid meist die ehrlichste Antwort istCloud-PKI vs. On-Prem ADCS — die ehrliche Entscheidungsmatrix
Wann der Cloud-Wechsel sich lohnt, wann er Quatsch ist und warum die meisten am Ende hybrid landen
Kurzfassung vorab
Vollständige Cloud-PKI-Migrationen sind selten. Sie passen für reine Cloud-First-Setups, für überschaubare Tech-Scaleups oder für Greenfield-Projekte ohne historische AD-Bindung. Wer ADCS produktiv mit Smartcard, S/MIME, NDES und Auto-Enrollment im Einsatz hat, bekommt von keinem aktuellen Cloud-PKI-Angebot diesen Funktionsumfang.
Das pragmatische Standardmodell heißt Hybrid: ADCS bleibt für alles, was Active Directory als Identitätsquelle braucht, und eine Cloud-PKI übernimmt die Disziplinen, in denen ADCS schwächelt — TLS via ACME, Container-Zertifikate, IoT-Massen-Enrollment. Die ehrliche Antwort auf „Cloud oder on-prem" lautet in 80 Prozent der Fälle: beides, mit klar abgegrenzten Verantwortlichkeiten.
Abb. 1: Drei Betriebsmodelle nebeneinander — die Hybrid-Variante kombiniert die Stärken der beiden Pole und ist in den meisten realen Setups die Zielarchitektur.
1. Was Cloud-PKI eigentlich ist — und was nicht
„Cloud-PKI" ist kein klar definierter Produktbegriff, sondern ein Sammelbegriff für mindestens vier verschiedene Angebotsklassen. Wer den Unterschied nicht kennt, vergleicht beim Einkauf Äpfel mit Birnen und wundert sich später über das Ergebnis.
Hyperscaler-PKI-Services
Microsoft Cloud PKI (Teil der Intune Suite), AWS Private CA und GCP Certificate Authority Service. Klassische Managed-CA-Services aus der jeweiligen Cloud, mit nativer ACME- bzw. SCEP-Schnittstelle, automatischer Skalierung und Abrechnung nach Volumen. Sehr stark für die jeweilige Cloud-Welt, schwächer beim Brückenschlag in den On-Prem-Stack.
Spezialisierte PKI-Management-Plattformen
Keyfactor Command, AppViewX, Venafi und Vergleichbares. Setzen sich vor existierende CAs (auch ADCS) und liefern Discovery, Renewal-Orchestrierung, Reporting, APIs. Streng genommen keine eigene PKI, sondern eine Verwaltungsschicht — aber im Markt oft unter „Cloud-PKI" mit eingereiht, weil die Plattform selbst als SaaS angeboten wird.
Klassische externe Zertifizierungsstellen mit Managed-PKI-Angebot
Sectigo Certificate Manager, GlobalSign Atlas, DigiCert Trust Lifecycle Manager. Liefern eine extern gehostete CA inklusive Webportal, API und Renewal-Automatisierung. Stärke: öffentlich vertrauenswürdige Zertifikate auf Abruf, gut für externe TLS-Workloads. Schwäche: nicht in die AD-Welt integriert.
Modernere ACME-native CAs
Smallstep step-ca (selbst gehostet oder als Smallstep Certificate Manager als SaaS), HashiCorp Vault PKI Secrets Engine. Konzeptuell die offensten und API-affinsten Angebote, sehr DevOps-tauglich. Für klassische Microsoft-Disziplinen wie Smartcard-Logon nicht gemacht.
|
Info · Verweis · Was alle Cloud-PKI-Angebote gemeinsam haben Sie nehmen dir die Plattformpflege ab — Patches, Hochverfügbarkeit, HSM-Hardware. Im Gegenzug nehmen sie dir auch ein Stück Kontrolle ab. Wer in einem regulierten Umfeld arbeitet, muss den Anbieter nicht nur funktional, sondern auch revisionssicher bewerten — bis zur Frage, welche Behörde wo welche Anordnung erteilen kann. |
|---|
2. Wo Cloud-PKI ihre Stärken ausspielt
Es gibt Disziplinen, in denen Cloud-PKI ADCS deutlich schlägt — nicht weil ADCS schlecht ist, sondern weil die Architektur dahinter aus einer anderen Welt stammt. Wer diese Disziplinen ehrlich beziffert, kommt schnell auf den Bedarf für einen Cloud-Anteil im PKI-Setup.
3. Wo Cloud-PKI heute nicht hinkommt
Nichts gegen Marketing, aber die Realität ist: Cloud-PKI ist kein Drop-in-Ersatz für ADCS. Eine Reihe von Disziplinen liefert sie schlicht nicht, oder nur als Notlösung. Wer ohne diese Klarheit migriert, baut sich ein böses Erwachen.
Abb. 2: Funktionsvergleich entlang der zehn häufigsten Disziplinen — die roten Felder sind die Stellen, an denen eine Komplettmigration nicht funktioniert.
Smartcard-Logon und Windows Hello for Business
Active-Directory-Anmeldung mit Smartcard oder TPM-gebundenem WHfB-Zertifikat braucht eine CA, die im AD veröffentlicht ist und der die Domänencontroller direkt vertrauen. Microsoft Cloud PKI kann inzwischen Smartcard-Logon für Intune-verwaltete Geräte, aber die klassische On-Prem-AD-Anmeldung mit physischer PIV-Karte am Domain-Controller bleibt eine Issuing-CA-im-AD-Disziplin. Andere Cloud-PKI-Anbieter spielen hier kaum mit.
S/MIME für interne User
Mit Auto-Enrollment ausgerollte User-Zertifikate, die in Outlook für Signatur und Verschlüsselung verwendet werden — der klassische Mittelstands-Use-Case. ADCS macht das im Schlaf. Bei Cloud-PKI ist S/MIME entweder gar nicht im Funktionsumfang oder über sehr spezifische Anbieter-Integrationen (DigiCert, Sectigo) abgebildet, die wieder eigene Komplexität mitbringen — und nicht in dieselbe Trustchain wie die Computer-Zertifikate fallen.
Datenhoheit über die CA-Schlüssel
Cloud-PKI bedeutet, dass die Private Keys der CA in einem HSM beim Anbieter liegen. Das HSM ist FIPS-zertifiziert, die Schlüssel sind nicht exportierbar, alles korrekt — aber sie liegen nicht bei dir. Für BSI-IT-Grundschutz-Hochsicherheit, KRITIS und Teile der NIS2-Auslegung ist das ein Diskussionspunkt mit Auditor und Datenschutz, der mindestens dokumentiert sein muss.
|
Warnung · Klassische Falle · Vendor-Lock-in ist bei PKI tiefer als bei anderen Cloud-Diensten Wenn du eine Cloud-Issuing-CA in Betrieb hast und der Anbieter morgen seinen Service einstellt oder die Preise verdoppelt, hast du nicht nur ein Migrationsthema. Du hast tausende Zertifikate im Umlauf, die einer Trustchain folgen, die du nicht weiterführen kannst. Migration heißt: alle Zertifikate neu ausstellen, mit Übergangsfrist. Das ist deutlich teurer als ein normaler Cloud-Provider-Wechsel. |
|---|
Codesigning und EV-CA
Eine eigene Codesigning-CA mit dedizierter Hierarchie und sehr restriktiver Härtung — Klassiker für Industrie und für alles, was eigene Software signiert. Die meisten Cloud-PKI-Angebote bieten Codesigning nur als externes, separat lizenziertes Produkt an, ohne Integration in die eigene Hierarchie. ADCS bleibt hier in vielen Setups die einzige Option, die das sinnvoll abbildet.
4. Entscheidungsmatrix — was passt zu welcher Lage
Aus zwei Achsen lässt sich für die meisten Unternehmen klar ableiten, welches Modell passt: die regulatorische Hoheits-Anforderung auf der einen, die Cloud-Affinität des Stacks auf der anderen Seite.
Abb. 3: Vier Quadranten, drei realistische Empfehlungen — vollständige Cloud-PKI als Standardempfehlung kommt in keinem Quadranten vor. Das ist Absicht.
Bewusste Botschaft dieser Matrix: Vollständige Cloud-PKI ist nirgendwo die naheliegende Empfehlung. Das hat zwei Gründe. Erstens deckt keiner der Anbieter den vollen ADCS-Funktionsumfang ab. Zweitens fängt der Wechsel auf Cloud-PKI in der Realität fast immer als Pilot für eine Teildisziplin (TLS, Intune) an und wächst von dort. Das ist genau der Hybrid-Pfad — nur ehrlich beschriftet.
Quadrant oben links — klassischer Mittelstand
Hoher Schutzbedarf, niedrige Cloud-Affinität. Industrie, Maschinenbau, KRITIS-Versorger. Hier bleibt ADCS on-prem die natürliche Wahl, eventuell ergänzt um eine ACME-Bridge für die TLS-Strecke. Cloud kommt höchstens für externe Partner-TLS rein, nicht für interne Identitäten.
Quadrant oben rechts — regulierte Cloud-Strategie
Hohe Hoheits-Anforderung, hohe Cloud-Affinität. Banken, Versicherer, große öffentliche Träger. Hier wird die Root und die primäre Issuing CA on-prem gehalten — die Cloud-Komponente kommt als Sub-CA mit klar definiertem, eng begrenztem Scope dazu. Das hält die Audit-Kette geschlossen und gibt trotzdem die Cloud-Flexibilität, wo sie gebraucht wird.
Quadrant unten links — keine Migration nötig
Kleine Dienstleister, Steuerkanzleien, klassische KMU mit gepflegtem ADCS. Solange die bestehende Umgebung läuft und keine konkreten Schmerzpunkte da sind, gibt es keinen Grund für einen Cloud-Schwenk. Höchstens punktuell eine ACME-Bridge oder ein Renewal-Tool ergänzen, sonst Ruhe bewahren.
Quadrant unten rechts — Hybrid mit Cloud-Schwerpunkt
Tech-Scaleups, cloud-first arbeitende Unternehmen. Hier landet die Mehrzahl der Container- und TLS-Workloads bei der Cloud-PKI, ADCS bleibt für die AD-integrierten Disziplinen. Wenn dieses Setup von Anfang an klar abgegrenzt ist, gibt es keinen Streit zwischen Identity- und Platform-Team.
5. Kosten ehrlich vergleichen
Der Marketing-Pitch der Cloud-PKI-Anbieter klingt so: kein HSM-Kauf, kein Server, keine Pflege, du zahlst nur, was du nutzt. Stimmt — bis du den fünften Jahresvertrag unterschreibst und merkst, dass das Volumen jedes Jahr ein bisschen wächst und die Abrechnung mit.
Abb. 4: Indikativer Kostenvergleich über fünf Jahre bei rund 5.000 Zertifikaten pro Jahr — Break-Even liegt typisch zwischen Jahr drei und fünf, danach kippt die Rechnung gegen die Cloud.
Die Werte in der Grafik sind ein Mittelweg aus mehreren Projekten und keine Liste-eines-konkreten-Anbieters. Reale Zahlen schwanken stark mit drei Faktoren: HSM-Klasse (ein YubiHSM 2 kostet 800 Euro, ein Thales Luna SA Network HSM eher 20.000+), Volumen (Cloud-PKI rechnet pro Zertifikat, ADCS-Kosten skalieren kaum mit der Anzahl) und Hochverfügbarkeitsanspruch (Geo-Redundanz on-prem verdoppelt die Hardware-Position).
|
Kostenkategorie |
ADCS on-prem |
Cloud-PKI |
|---|---|---|
|
Anfangsinvestition (Jahr 1) |
30.000–50.000 € (HSM, 2 VMs, Setup, Härtung, Dokumentation) |
15.000–25.000 € (Onboarding, Integration, Schulung) |
|
Laufende jährliche Kosten |
8.000–15.000 € (Pflege, Patches, Renewal-Zyklen) |
12.000–25.000 € (Subscription + Volumen) |
|
Skalierung bei +50% Zertifikate |
marginal (gleiche CA, mehr Templates) |
spürbar (Volumen-basierte Abrechnung) |
|
Wechsel des Anbieters |
keiner — du bist dein Anbieter |
sehr aufwendig: alle Zertifikate neu ausstellen |
|
Personalbedarf für laufenden Betrieb |
0,2–0,5 FTE |
0,1–0,2 FTE |
|
Praxis-Tipp · Aus dem Beratungsalltag · Die unsichtbaren Kosten beider Modelle nicht vergessen Bei on-prem fehlen in den meisten Rechnungen die internen Personalkosten für Patches, Audit-Begleitung und Notfall-Handling. Bei Cloud-PKI fehlen die Integrationskosten für jeden neuen Cloud-CA-Anschluss an die bestehende Tooling-Landschaft (Monitoring, Reporting, CMDB). Wer ehrlich kalkuliert, addiert pro Modell zwischen 5.000 und 15.000 Euro pro Jahr an versteckten Posten. |
|---|
6. Wie ein gesundes Hybrid-Setup praktisch aussieht
Wenn der Hybrid-Pfad die ehrliche Antwort für die meisten Unternehmen ist, lohnt sich ein Blick darauf, wie das konkret gebaut wird. Drei Aufbau-Varianten sehe ich in Projekten regelmäßig:
Variante A — ADCS bleibt Wurzel, Cloud-PKI als Subordinate
Die ADCS-Issuing-CA stellt ein Sub-CA-Zertifikat für die Cloud-PKI aus. Alle Zertifikate, die aus der Cloud kommen, hängen technisch an deiner Root. Endgeräte müssen nur deiner Root vertrauen — die Cloud-Chain wird automatisch validiert. Vorteil: ein Trust-Anker. Nachteil: nicht jede Cloud-PKI lässt sich als Sub-CA hinter einer ADCS-Root betreiben (Microsoft Cloud PKI tut sich damit aktuell schwer, AWS Private CA und Smallstep gehen gut).
Variante B — Parallelbetrieb mit Cross-Trust
ADCS und Cloud-PKI haben jede eine eigene Root. Endgeräte vertrauen beiden. Das ist die häufigste Form, weil sie nichts an der Cloud-CA-Konfiguration ändert und sich pragmatisch nachrüsten lässt. Wichtig: beide Roots per GPO oder Intune sauber verteilen, sonst gibt es bei den ersten Zertifikatswarnungen Beschwerden.
Variante C — Cloud-PKI nur für definierte Use Cases
Cloud-PKI wird nur für sehr klar abgegrenzte Workloads eingesetzt, typisch Container-TLS oder externe Partner-Zertifikate. Die ausgestellten Zertifikate werden bewusst nicht in den allgemeinen Trust Store des Unternehmens gehoben, sondern nur dort, wo sie gebraucht werden (Kubernetes-Cluster, dedizierte Load-Balancer). Diese Variante hat den geringsten Audit-Footprint, weil die Cloud-Komponente einen sehr begrenzten Scope hat.
|
PowerShell — ADCS-Root-Zertifikat zusätzlich in die Trust-Liste eines Cloud-Workloads aufnehmen # Beispiel: Linux-VM (z. B. in Azure) soll Zertifikaten aus der # internen ADCS-Hierarchie vertrauen, parallel zur Cloud-PKI-Root.
# Schritt 1: ADCS-Root-Zertifikat exportieren (auf einem Domain- # joined Windows-Host ausführen) $rootCert = Get-ChildItem Cert:\LocalMachine\Root | ` Where-Object { $_.Subject -like "*CN=Musterwerk Root CA*" }
Export-Certificate ` -Cert $rootCert ` -FilePath C:\Temp\musterwerk-root.cer ` -Type CERT
# Schritt 2: in PEM konvertieren (für Linux/Container) certutil -encode C:\Temp\musterwerk-root.cer ` C:\Temp\musterwerk-root.pem
# Schritt 3: auf der Linux-VM ablegen und Trust-Store aktualisieren # (auf Ubuntu/Debian) # sudo cp musterwerk-root.pem /usr/local/share/ca-certificates/` # musterwerk-root.crt # sudo update-ca-certificates
# Schritt 4: für cert-manager im Kubernetes-Cluster als # additionalTrustedCAs in den ClusterIssuer eintragen. |
|---|
Praxis-Beispiel — Musterwerk GmbH
Musterwerk ist ein Maschinenbau-Mittelständler mit knapp 1.400 Beschäftigten, drei Standorten in Deutschland und einer wachsenden Werkshalle in Polen. Die ADCS-Umgebung läuft seit über zehn Jahren — zweistufig, mit HSM, sauber gepflegt. NIS2 ist seit dem letzten Audit ein konkretes Thema, gleichzeitig hat die IT-Strategie den Auftrag bekommen, eine „Cloud-First-Roadmap" zu liefern.
Erste Reaktion in der Geschäftsführung: „Lass uns die PKI doch komplett in die Cloud heben." Erste Reaktion im Workshop: drei Stunden später war klar, dass das nicht funktioniert. Smartcard-Logon für die Werkhallen-Industrie-Clients lässt sich aktuell nicht sinnvoll in eine externe Cloud-PKI verlagern. S/MIME für die 1.400 User auch nicht. Codesigning für die SPS-Firmware schon gar nicht.
Die getroffene Entscheidung war eine Variante-B-Hybrid: ADCS bleibt unverändert für alle internen Use Cases, Microsoft Cloud PKI kommt als zweite, gleichberechtigte Issuing-CA für die wachsende Intune-Flotte und für die Container-Workloads in Azure. Beide Roots werden per GPO und Intune in alle relevanten Trust-Stores ausgerollt. Die Kosten-Rechnung über fünf Jahre landet im Hybrid-Modell bei einer leichten Mehrbelastung gegenüber „ADCS allein lassen", aber deutlich unter „Komplett-Migration in die Cloud". Die regulatorische Hoheit über die unternehmenskritischen Identitäten bleibt im Haus.
Erfahrung aus diesem Projekt: Der eigentliche Wert des Workshops lag nicht in der finalen Architektur, sondern darin, die Erwartungen der Geschäftsführung an die Realität heranzuführen. „Komplett in die Cloud" war kein technischer Plan gewesen, sondern eine Hoffnung — und Hoffnungen sind keine PKI-Strategie.
Verwandte Themen
Häufige Fragen (FAQ)
Wann lohnt sich der vollständige Wechsel auf Cloud-PKI?
Sehr selten, und meistens nur in Greenfield-Setups oder in reinen Cloud-First-Unternehmen ohne signifikante AD-Bindung. Sobald Smartcard-Logon, S/MIME für interne User oder Codesigning produktiv im Einsatz sind, scheitert die Komplettmigration an der schlichten Tatsache, dass die meisten Cloud-PKI-Anbieter diese Disziplinen nicht oder nur als Notlösung abbilden.
Was ist der Unterschied zwischen Microsoft Cloud PKI und Azure Key Vault Managed HSM?
Microsoft Cloud PKI ist eine fertige Managed-CA für Intune-verwaltete Geräte, Teil der Intune Suite. Azure Key Vault Managed HSM ist eine reine HSM-Hardware in der Cloud — du kannst damit eine eigene CA betreiben, musst aber die CA-Logik selbst bauen. Für klassische Unternehmens-PKI ist Microsoft Cloud PKI der naheliegende Microsoft-Weg, Key Vault Managed HSM eher für Spezialfälle.
Wie löse ich das Vendor-Lock-in-Problem bei Cloud-PKI?
Komplett vermeiden lässt es sich nicht. Aber du kannst es eingrenzen, indem du erstens kurze Laufzeiten ausstellst (47–90 Tage statt mehrere Jahre), zweitens den Cloud-PKI-Scope klein hältst (nur TLS, nicht alle Disziplinen), und drittens eine Migrationsrechnung in der Schublade hast, die du jährlich aktualisierst. Wenn du weißt, was ein Wechsel kosten würde, verhandelst du auch besser mit dem aktuellen Anbieter.
Kann ich ADCS und eine Cloud-PKI gleichzeitig betreiben, ohne dass es Konflikte gibt?
Ja, das ist sogar der Normalfall im Hybrid-Modell. Wichtig ist eine klare Aufgabenteilung — welche CA stellt welche Zertifikatstypen aus, welche Hostnamen-Räume sind getrennt, wie ist der Trust-Anchor-Rollout geregelt. Wenn diese drei Punkte sauber dokumentiert sind, gibt es keine Konflikte. Ohne diese Klarheit gibt es Beschwerden über doppelt ausgestellte Zertifikate und unklare Verantwortlichkeiten.
Wie wirkt sich die 47-Tage-TLS-Regel auf die Entscheidung aus?
Stark — und zwar in Richtung Hybrid. Die 47-Tage-Regel ab März 2029 macht ACME-Automation für TLS faktisch zur Pflicht. Wer ADCS behält, braucht entweder eine ACME-Bridge (siehe Spoke 6.5) oder eine Cloud-PKI als zweites Standbein für die TLS-Strecke. Das ist häufig der konkrete Auslöser, der Unternehmen aus dem unteren Quadranten in den Hybrid-Quadranten schiebt.
Wie steht es um Post-Quantum bei Cloud-PKI-Anbietern?
Stand heute haben weder Microsoft Cloud PKI noch AWS Private CA noch GCP CAS eine produktive ML-DSA-Unterstützung. Smallstep und einige PKI-Management-Plattformen experimentieren damit. Wer Post-Quantum aktiv in den nächsten zwei bis drei Jahren angehen will (siehe Spoke 6.3), wird hier mit allen Anbietern noch Pioniergespräche führen. ADCS ist hier nicht zwingend hinten — alle sind ungefähr gleich weit.
Nächste Schritte mit boddenberg.de
Die Cloud-vs.-On-Prem-Frage ist selten eine reine Technologie-Entscheidung. Sie hängt an Compliance, an der Cloud-Strategie des Hauses, an internen Verantwortlichkeiten und am ehrlich kalkulierten Wirtschaftlichkeitsbild. Drei Wege, das mit mir gemeinsam zu klären:
Wer parallel die TLS-Erneuerungslogik auf Microsoft-Servern modernisieren will, sollte sich CertBinder anschauen (siehe Spoke 5.2) — das adressiert genau die Strecke zwischen Issuing-CA und IIS/Exchange/ADFS, die in jedem Hybrid-Setup eine eigene Disziplin ist.
Kontakt: Uli Boddenberg · boddenberg.de · Dortmund